Hi Eric, comments inside..
2010/11/30 Eric Charles <[email protected]>: > Hi, > > The mailbox-store provides base/common logic to all stores. > There seems to be a trend to add more shared functions in it, namely: > > 1.- LastUidTracker replacing the getLastUid() method that was implemented in > each store. > > 2.-MailboxPathLocker used when creating/renaming mailbox. The extra classes > really brings bring ease when reading code and allows implementation for > distributed locking. > > 3.- MailboxIndex for search optimization (ongoing work) I think you talk about the lucene index stuff which I proposed for Maildir. I would be in favor to make it generic so that implementations can reuse or use their own search index if they like.. So I think we are "in-line" here.. > > I was also thinking to a 4th area, the UID management (UidProvider) we > talked before on https://issues.apache.org/jira/browse/IMAP-193. > Currently, UID are assigned by the store impl (if you use JPA, it must be > JPA and so on...). This is done in different ways (see code after for > jpa/jcr/maidir). > We could define a UidProvider to get rid of different locking mechanism and > have an efficient and distributed way to manage/generate the UIDs. > JPA/JCR/... and could benefit from this default implementation. (JPA could > probably be ameliorated with a auto_increment rather than a database lock to > manage the UID, but I think there will be a non-optimum usage of the key > space). That makes sense. In most cases we could also just use the MailboxPathLocker with an AtomicLong for the generation. Just read the last uid for a mailbox on select or startup and then use the AtomicLong. > > We may also discuss a layer implementing distributed MailboxListeners (to > have a base for distributed James, and transfer the needed > LastUidTracker,... events). I already have something in mind here > > Are there any other areas we could define as the mailbox-store > responsibility? > > Tks, > > Eric > > Locking for new UID for JPAMessageMapper > ====================================== > protected long reserveUid(JPAMailbox mailbox) { > EntityManager manager = getEntityManager(); > > // we need to set a pessimistic write lock to be sure we don't get > any problems with dirty reads etc. > JPAMailbox m = manager.find(JPAMailbox.class, mailbox.getMailboxId(), > LockModeType.PESSIMISTIC_WRITE); > manager.refresh(m); > m.consumeUid(); > manager.persist(m); > return m.getLastUid(); > } > } > > Locking for new UID for JCRMessageMapper > ======================================= > protected long reserveNextUid(Mailbox<String> mailbox) throws > RepositoryException, InterruptedException { > long result = getNodeLocker().execute(new > NodeLocker.NodeLockedExecution<Long>() { > > public Long execute(Node node) throws RepositoryException { > Property uidProp = > node.getProperty(JCRMailbox.LASTUID_PROPERTY); > long uid = uidProp.getLong(); > uid++; > uidProp.setValue(uid); > uidProp.getSession().save(); > return uid; > } > > public boolean isDeepLocked() { > return true; > } > > }, getSession().getNodeByIdentifier(mailbox.getMailboxId()), > Long.class); > return result; > > } > > > Locking for new UID for MaildirMessageMapper (in MaildirFolder) > ========================================================= > > /** > * Locks the uidList file and if it has retrieved the lock, returns it. > * Make sure to call unlockUidList() in a finally block afterwards. > * @return The locked uidList > */ > public File lockUidList() { > FileLock.lock(uidFile); > return uidFile; > } > > /** > * Unlocks the uidList file if it has been locked before. > */ > public void unlockUidList() { > FileLock.unlock(uidFile); > } > > > Thx for your comments! Bye, Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
