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 Fri, 07 May 2010 04:58:22 GMT
Hi Robert,

to be honest I think it would make things just more complicated. I
think we should just make sure we keep the jcr session / entitymanager
etc open till we are done with processing the request. Nothing more...

I don't see the advance of implement such a callback interface. Maybe
you can outline why you "prefer" this way ?

Thx,
Norman


2010/5/6 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
> On Thu, May 6, 2010 at 9:17 PM, Norman Maurer
> <norman.maurer@googlemail.com> wrote:
>> Hi Eric,
>>
>> comments inside..
>>
>> 2010/5/6 Eric I. <eric@linuxbox.com>:
>>> Tim-Christian Mundt <dev <at> tim-erwin.de> writes:
>>>> > 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?
>>>
>>> Yes, it does throw an exception --
>>>
>>> javax.jcr.RepositoryException: Only one active session is allowed per thread.
>>>        at
>>> org.apache.james.imap.jcr.JCRMailboxManager.getSession
>>>        (JCRMailboxManager.java:115)
>>>        at
>>> org.apache.james.imap.jcr.JCRMailboxManager.createMailboxMapper
>>>        (JCRMailboxManager.java:91)
>>>        at org.apache.james.imap.jcr.JCRMailboxManager.doCreate
>>>        (JCRMailboxManager.java:123)
>>>        at
>>> org.apache.james.imap.store.StoreMailboxManager.createMailbox
>>>        (StoreMailboxManager.java:198)
>>> ...
>>>
>>>> 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.
>>>
>>> So that makes sense -- a client can make multiple requests, each request gets
>>> its own JCR session. Quickly scanning the current IMAP code it does not appear
>>> that threads are spawned to handle various requests from a given client. In
>>> other words, it appears as though a given client's requests are serialized. Is
>>> that correct? If so, then I'd think that a session can be made at the start of
a
>>> request's processing, and then .logout() can be called on the JCR session to
>>> release it. The same thread would get a new JCR session when it processes the
>>> next request.
>>>
>>> Eric
>>
>> My plan would be to have some kind of request scoped session pattern.
>> Something like this but just for JCR/JPA etc..:
>>
>> http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/orm/jpa/support/OpenEntityManagerInViewFilter.html
>>
>> So the Session/EntityManager is re-used the whole request.
>> For this it should get created in teh startProcessingRequest(...)
>> method and closed in the endProcessingRequest(...) method.
>
> FWIW the way i'd intended to flip the API was to allow access to many
> methods through a call back interface eg
>
> interface MailboxTransactionRequest {
>
> public Response process(Mailbox mailbox);
>
> }
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>

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


Mime
View raw message