james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: (JDBC)MailRepository and locking
Date Tue, 06 Jun 2006 16:11:23 GMT
Hi Joachim,

You did a good review of the current repository and his problems.
I almost agree on everything you wrote.

Joachim Draeger wrote:
> Hi!
> I understand Lock as following: I can do everything when the message is 
> not locked or is locked by myself (my thread).
> remove(String key); only removes a message when it is not locked or 
> locked by myself.
> 1. Shouldn't it throw an exception, when it couldn't obtain a lock?

It would be much more easy to understand and manage.
I don't know if this could ever happen now or if we only remove locked 

> store(Mail mc); locks a message if it was not locked. It unlocks it 
> afterwards, if it was not locked before.
> 2. Shouldn't it test if obtaining lock was successful and if necessary 
> throw an exception?

Perhaps yes.

> retrieve(String key) isn't using locks at all.
> 3. Shouldn't it make use of locking to?
>   - I shouldn't retrieve a message someone else is going to delete or 
> update
>   - I shouldn't delete/update a message that is being retrieved at the 
> same time

Maybe this should be managed by transaction and not by locks that 
prevent you from deleting/updating a message being retrieved

>   - But: I should be able to retrieve a message another thread is 
> retrieving at
>     the same time.


> 4. do we have to differentiate between locked because of modifying or 
> locked
>    because of retrieving?

Not sure we can, but I would try to avoid using read/write locks if we 
can manage things with a single lock.

> Lock has a method boolean canI(final Object key);
> 5. Nobody should make a decision because of result of canI: it could be 
> changed
>    at the same moment. It doesn't seem to be used anywhere. Should we 
> remove it?

I also agree to remove unused code.

I think that we should discuss only of SpoolRepositories because 
MailRepository should be deprecated in favor of a new MessageRepository 
with different concepts.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message