Hi Eric, thx to follow up on this. Comments inside
2010/5/11 Eric Charles <eric.char...@u-mangate.com>: > 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). Which brings me to a JCRStressTest which fails :/ > > 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. Going this way would allow to use the "most" performant solation per implementation. This would also allow us to support clustering in JCR etc. That would not be possible when using a "JVM lock". Locking in JCR is an other problem, but I will do some more research first before go into the details > > 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. See above... > > 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. What is different here from what we have atm in the abstract method of StoreMailbox ? > > 4. Design and implement a more evolved solution that would, per mailbox, > maintain the lastuid and queue all uid generation request per mailbox. > Could you give me some more details about how you think this could be done ? At the moment I think about adding an interface called UidConsumer. Which only has one method like: long reserveNextUid(Mailbox mailbox, MailboxSession session); The instance of the Consumer would get instances in the StoreMailboxManager and then passed to the StoreMailbox in the constructor. So it would be easy for developers to provide their own strategy. > So the question is "to which strategy should be go" ? > > Eric > > Bye, Norman --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
