(JDBC)MailRepository and locking

[Joachim Draeger <jd...@joachim-draeger.de>]

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?

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?

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
   - 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?

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 don't know whether I'm right or anything should be changed there. Just to 
clarify things and keep in mind for MessageRepository.

Joachim




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

Re: (JDBC)MailRepository and locking

[Joachim Draeger <jd...@joachim-draeger.de>]

Hi Stefano,

Stefano Bagnara schrieb:

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

I'm not familiar with James spooling. For the MessageRepository: Maybe it should 
get a long without locks and threads should wait for internal operations, on the 
same message, to complete.
- remove() waits until all concurrent retrieve/store operations have finished 
but new attempts will fail.
- store() waits until running retrieve operations have finished and new retrieve 
attempts wait for that store();
Just like a queue. Maybe it gets sorted and maybe multiple removes get sorted 
out. Okay, maybe it's too complicated. :-) But for the "client" it would be much 
easier, it can trust that his operation will succeed.


Joachim

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

Re: (JDBC)MailRepository and locking

[Stefano Bagnara <ap...@bago.org>]

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 
mails.

> 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.

Yes.

> 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.

Stefano


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