james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <norman.mau...@googlemail.com>
Subject Re: James IMAP and Alfresco and refactoring
Date Wed, 05 May 2010 11:52:58 GMT
Hi comments inline..

2010/5/5 Tim-Christian Mundt <dev@tim-erwin.de>:
> Hi!
>> Alfresco's JCR implementation only allows one session per thread.
> I think Alfresco stores the session stuff in a Thread Local variable (at
> least using web services), so there can be only one active session at a time
> per thread. However, what does prevent you from simply creating a new one
> overriding the old (which is then lost of course)? Does it throw an
> exception? On the other hand:
>> 2) And is there a good reason not to change James IMAP's JCR
>> implementation to re-use JCR sessions rather than create new ones for a
>> given client?
> Sessions contain transactions, so if one mailbox is accessed from several
> clients simultaneously, we need one session for each client. Using the
> global mailbox/manager there is definitely a need for creating several
> sessions, unless I'm mistaken. Each IMAP request needs its own transaction,
> hence sessions cannot be shared.
> Within one single request I think we don't need several sessions. The JCR
> sessions should simply be stored in the James sessions. So "getSession" in
> Mailbox and MailboxManager would need to be slightly adjusted.

Yeah that would be the best thing in terms of session creation. One
JCRSession per imapsession. The only problem I see here is, if we have
concurrent access to a mailbox we need to make sure that changes are
seen by concurrent connectors. So if one connector deletes a mailbox
the other need to get notified.  Its a bit of pita.. So we need todo
some session refresh in this cases to make sure we don't get "old"
data. So maybe it would be easier to get a new JCR Session per request
and do some kind of locking during the request processing, so we don'T
need to fight with to much things the same time..

>> Would it be worth discussing where James IMAP is going in the near-term
>> and whether we should coordinate.
> You are totally right. I'd be glad if we could find a good design for IMAP
> and implement it as soon as possible, not least because my maildir
> implementation will be affected by this process. I'd like to build on a
> relatively stable structure. That would, by the way, be my only objection to
> releasing James too soon. First we should stabilize the IMAP stuff.
> Regards
> Tim

Me too. I did a lot of refactoring over the last weeks and sometimes I
feel like just turning cycles.. I the long term I would like to see
some kind of async processing for mailboxes. But I think thats not
feasible in the short term.


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

View raw message