Hi,
Section 2.3.1.1 of IMAP RFC (http://www.faqs.org/rfcs/rfc3501.html)
states that Unique identifiers MUST be strictly ascending in the mailbox
at all times.
This is currently enforced in
org.apache.james.imap.store.mail.model.Mailbox#consumeUid() for the JPA
store.
A JPAStressTest has been setup by Norman to verify that the uid were
correctly generated.
This showed that parallel threads could give issues in critical section
of org.apache.james.imap.jpa.JPAMailbox#reserveNextUid(mailboxSession)
(the section between the transaction begin and commit).
After chatting and patching with Norman, at least 4 strategies are
identified:
1. Use locking specific mecanism of each store. This is what is actually
implemented for database store (via LockModeType.PESSIMISTIC_WRITE and
adequate timeout) on JPAMaibox. The JCR store would need something
similar. Simply document the reserveNextUid to indicate that a locking
mecanism should be implemented. Currently, this solution works for JPA
and uid are correctly generated.
2. Implement some ReentrantLock (or equivalent synchronization) an
abstraction level higher. All specific implementations would benefit
from this mecanism. Lock would be for all maiboxes.
3. Change in a way the api (change
org.apache.james.imap.mailbox.Mailbox#appendMessage signature for
example) to oblige each implementation to have a threadsafe way of
generating the uid.
4. Design and implement a more evolved solution that would, per mailbox,
maintain the lastuid and queue all uid generation request per mailbox.
So the question is "to which strategy should be go" ?
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
