You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by John Tranier <jo...@fylab.com> on 2010/01/21 18:41:41 UTC
JCR session handling
Hi everybody,
I would like to have advices about how I should handle JCR sessions in
my application context.
I have read the guide on the wiki, but I'm not clear about what is
called "transient mods", if my application fall into it, and finally how
to deal with that case.
I am using a Jackrabbit repository to handle personal storage space for
users of my web application. I've defined personalized access for each
users, so it's about personalized accounts.
Up to now, I've handled sessions by creating a session for each http
request. But since my application makes use of AJAX to display the tree
view of the personal space of a user, a lot of requests may be launched
in sequence, causing a lot of login/logout...
Would it be a better practice to use a http session scope instead of
request scope, with eventually a TTL after which a session would be closed?
Thanks in advance,
John
Re: JCR session handling
Posted by ChadDavis <ch...@gmail.com>.
On Thu, Jan 21, 2010 at 10:41 AM, John Tranier <jo...@fylab.com> wrote:
> Hi everybody,
>
> I would like to have advices about how I should handle JCR sessions in my
> application context.
> I have read the guide on the wiki, but I'm not clear about what is called
> "transient mods", if my application fall into it, and finally how to deal
> with that case.
>
I can provide a little insight. The Jackrabbit architecture makes a
distiniction between the transient layer and the persistent layer.
The transient layer is where local changes in your session are; they
haven't been persisted to the persistent layer. The persistent layer
is the layer implemented by the persistence manager; pm's are the
module's responsible for writing to disk or db or whatever. I believe
the transient layer is roughly equal to the Session object, and the
persistent layer is roughly equal to the persistence manager object.
Hope that helps a bit.
> I am using a Jackrabbit repository to handle personal storage space for
> users of my web application. I've defined personalized access for each
> users, so it's about personalized accounts.
>
> Up to now, I've handled sessions by creating a session for each http
> request. But since my application makes use of AJAX to display the tree view
> of the personal space of a user, a lot of requests may be launched in
> sequence, causing a lot of login/logout...
>
> Would it be a better practice to use a http session scope instead of request
> scope, with eventually a TTL after which a session would be closed?
>
> Thanks in advance,
> John
>
>
>
Re: JCR session handling
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 22.01.2010 14:46, John Tranier wrote:
> Thanks for all your answers, it definitely helps me a lot.
>
> Felix, your point is good.
> I cannot use the HTTP session since several HTTP requests can occur at
> the same time for a single user (because of AJAX), that would not be
> thread safe.
>
> One more question: Is there a way to check if there is no more open
> session on a repository? I would need that to write a test that ensures
> no session remains open at the end of my use cases.
AFAICT there is no official API reporting the number of open sessions.
But you could create Repository and Session wrappers and implement a
counter incremented on session creation and decremented on logout.
Regards
Felix
>
> Regards,
> John
>
>
> Felix Meschberger a écrit :
>> Hi,
>>
>> Over in Apache Sling, we create new sessions for each request.
>>
>> We used to have Session pooling (maintain a pool of open sessions per
>> user to be reused on future requests). But this proved unstable and
>> slower than calling Repository.login on each request (!) and we will
>> remove the Session pool code in the near future.
>>
>> We do not use any HTTP Session. Also we do not share sessions between
>> requests. The problem, you will have doing this is, that Session objects
>> are not thread safe.
>>
>> So while reading from the same session concurrently will generally be
>> rather safe (no guarantee, though), writing concurrently with the same
>> sessions is a guaranteed failure.
>>
>> Hope this helps.
>>
>> Regards
>> Felix
>>
>> On 21.01.2010 18:41, John Tranier wrote:
>>
>>> Hi everybody,
>>>
>>> I would like to have advices about how I should handle JCR sessions in
>>> my application context.
>>> I have read the guide on the wiki, but I'm not clear about what is
>>> called "transient mods", if my application fall into it, and finally how
>>> to deal with that case.
>>>
>>> I am using a Jackrabbit repository to handle personal storage space for
>>> users of my web application. I've defined personalized access for each
>>> users, so it's about personalized accounts.
>>>
>>> Up to now, I've handled sessions by creating a session for each http
>>> request. But since my application makes use of AJAX to display the tree
>>> view of the personal space of a user, a lot of requests may be launched
>>> in sequence, causing a lot of login/logout...
>>>
>>> Would it be a better practice to use a http session scope instead of
>>> request scope, with eventually a TTL after which a session would be
>>> closed?
>>>
>>> Thanks in advance,
>>> John
>>>
>>>
>>>
>>>
>>
>>
>
>
Re: JCR session handling
Posted by John Tranier <jo...@fylab.com>.
Thanks for all your answers, it definitely helps me a lot.
Felix, your point is good.
I cannot use the HTTP session since several HTTP requests can occur at
the same time for a single user (because of AJAX), that would not be
thread safe.
One more question: Is there a way to check if there is no more open
session on a repository? I would need that to write a test that ensures
no session remains open at the end of my use cases.
Regards,
John
Felix Meschberger a écrit :
> Hi,
>
> Over in Apache Sling, we create new sessions for each request.
>
> We used to have Session pooling (maintain a pool of open sessions per
> user to be reused on future requests). But this proved unstable and
> slower than calling Repository.login on each request (!) and we will
> remove the Session pool code in the near future.
>
> We do not use any HTTP Session. Also we do not share sessions between
> requests. The problem, you will have doing this is, that Session objects
> are not thread safe.
>
> So while reading from the same session concurrently will generally be
> rather safe (no guarantee, though), writing concurrently with the same
> sessions is a guaranteed failure.
>
> Hope this helps.
>
> Regards
> Felix
>
> On 21.01.2010 18:41, John Tranier wrote:
>
>> Hi everybody,
>>
>> I would like to have advices about how I should handle JCR sessions in
>> my application context.
>> I have read the guide on the wiki, but I'm not clear about what is
>> called "transient mods", if my application fall into it, and finally how
>> to deal with that case.
>>
>> I am using a Jackrabbit repository to handle personal storage space for
>> users of my web application. I've defined personalized access for each
>> users, so it's about personalized accounts.
>>
>> Up to now, I've handled sessions by creating a session for each http
>> request. But since my application makes use of AJAX to display the tree
>> view of the personal space of a user, a lot of requests may be launched
>> in sequence, causing a lot of login/logout...
>>
>> Would it be a better practice to use a http session scope instead of
>> request scope, with eventually a TTL after which a session would be closed?
>>
>> Thanks in advance,
>> John
>>
>>
>>
>>
>
>
Re: JCR session handling
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Over in Apache Sling, we create new sessions for each request.
We used to have Session pooling (maintain a pool of open sessions per
user to be reused on future requests). But this proved unstable and
slower than calling Repository.login on each request (!) and we will
remove the Session pool code in the near future.
We do not use any HTTP Session. Also we do not share sessions between
requests. The problem, you will have doing this is, that Session objects
are not thread safe.
So while reading from the same session concurrently will generally be
rather safe (no guarantee, though), writing concurrently with the same
sessions is a guaranteed failure.
Hope this helps.
Regards
Felix
On 21.01.2010 18:41, John Tranier wrote:
> Hi everybody,
>
> I would like to have advices about how I should handle JCR sessions in
> my application context.
> I have read the guide on the wiki, but I'm not clear about what is
> called "transient mods", if my application fall into it, and finally how
> to deal with that case.
>
> I am using a Jackrabbit repository to handle personal storage space for
> users of my web application. I've defined personalized access for each
> users, so it's about personalized accounts.
>
> Up to now, I've handled sessions by creating a session for each http
> request. But since my application makes use of AJAX to display the tree
> view of the personal space of a user, a lot of requests may be launched
> in sequence, causing a lot of login/logout...
>
> Would it be a better practice to use a http session scope instead of
> request scope, with eventually a TTL after which a session would be closed?
>
> Thanks in advance,
> John
>
>
>
Re: JCR session handling
Posted by Rakesh Vidyadharan <ra...@sptci.com>.
On 21 Jan 2010, at 11:41, John Tranier wrote:
> Hi everybody,
>
> I would like to have advices about how I should handle JCR sessions in my application context.
> I have read the guide on the wiki, but I'm not clear about what is called "transient mods", if my application fall into it, and finally how to deal with that case.
>
> I am using a Jackrabbit repository to handle personal storage space for users of my web application. I've defined personalized access for each users, so it's about personalized accounts.
>
> Up to now, I've handled sessions by creating a session for each http request. But since my application makes use of AJAX to display the tree view of the personal space of a user, a lot of requests may be launched in sequence, causing a lot of login/logout...
>
> Would it be a better practice to use a http session scope instead of request scope, with eventually a TTL after which a session would be closed?
Yes, I have been using a HTTP Session scope JCR session for the applications I have built. I use both Context and Session listeners to close all sessions that are active.
Rakesh