Jukka Zitting ha scritto: > Hi, > > On 5/14/07, Jukka Zitting <[EMAIL PROTECTED]> wrote: >> I'll probably come up with more questions, [...] > > Locking: > > * Should a message lock be visible to other processes that access the > same repository?
Visible? Well, it depends on what you mean by visible. SpoolRepository.accept() take care of returning non locked objects. MailRepository.remove try to lock the message and fails if someone else already locked. > * Should a message lock automatically prevent other clients form > modifying the node or just from acquiring the lock? IIRC MailRepository does not have correct support for this scenario. If the store is a mailrepository then it never happen (in real cases) that we access the same object with multiple thread concurrently to change the same message. In case it is a spoolrepository you're supposed to obtain messages via accept method, and in this case you have an exclusive lock on it. Everything in that interfaces can be improved with much more strict contracts. > * Who can release a mesage lock? I notice that the Lock utility class > always binds a lock to the current thread. The thread that own the lock can unlock. Of course if we plan to move to SEDA this will need to be changed or it will break our spoolrepositories locking. > * What happens if a client fails to unlock a message? I think fail on unlock is not handled at all (is it possible?). > Mail lifecycle: > > * Is there a defined lifecycle for Mail instances? I'm thinking about > associating a JCR session with a Mail instance to allow on-demand > loading and incremental updates of mail messages, but to properly > release the session I'd need some way to know when the Mail instance > is no longer in use. We always call ContainerUtil.dispose(mailobject). If the Mail implementation implements Disposable we call mailobject.dispose(). In our default Mail implementation (MailImpl) we also take care to call ContainerUtil.dispose(message) and if it is a MimeMessageCopyOnWriteProxy this updates the referencecounters, and if no one reference to the MimeMessageWrapper then also dispose for the MimeMessageWrapper is called. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
