Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <422623F7.6080400@apache.org>
References: <4225DDEA.9090609@apache.org>
 <f2fbc46df58915939b85ff4158c6a82b@mac.com> <422623F7.6080400@apache.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <f2f5d6697b32b51ac148b901923cae5c@mac.com>
Content-Transfer-Encoding: 7bit
From: "Suhail M. Ahmed" <ilyanov@mac.com>
Subject: Re: Lifetime of a session?
Date: Wed, 2 Mar 2005 23:13:34 +0100
To: jackrabbit-dev@incubator.apache.org

Looking In terms of isolation, the save implementation in ItemImpl 
synchronizes on the instance of session so concurrent updates should be 
serialized. As for transactions. things are naturally a "bit" more 
involved. I haven't looked at the code long enough to have figured out 
the bits yet. I can see that something called 
TransactionalItemStateManager is instanced in the Workspace 
implmentation and this same instance is passed into the Session 
(XASessionImpl in this case). I can also see that Observable pattern is 
used to couple item, session and transactionalItemstatemanger beyond 
that i feel like a zen monk staring at a blank wall. I will continue 
staring till the shoe drops. But more pointedly, I think the spec is 
quite clear in terms of how a jcr-170 implementation aught to work in a 
concurrent and multi-repository setup (hence the requirement for 
XASession). Since Jackrabbit is the reference implementation, I would 
trust it to implement the spec faithfully.

Suhail

On Mar 2, 2005, at 9:37 PM, Sylvain Wallez wrote:

> Suhail M. Ahmed wrote:
>
>> Hi Sylvain,
>>
>> The Session object is returned on performing a login on the 
>> repository. Looking at RepositoryIml you will see
>>
>>  Session ses = new XASessionImpl(this, lc, wspInfo.getConfig());
>>  activeSessions.put(ses, ses);
>>
>> You should I think couple the repository session life cycle to your 
>> http session life cycle. I haven't dug deeper in to the object graph 
>> derived from session so I can't say anything about the thread safety 
>> of Item and its sub classes. I do see some nifty synchronization in 
>> the content store implementation so I would think that at that level 
>> things are thread safe. I think the optimum route is to use a session 
>> listener to login and logout from the repository.
>
>
> That was my opinion also, but the thread-safety on session itself may 
> be a concern if a single user issues several request simultaneously. 
> How will the transaction manager behave in such circumstances?
>
> Sylvain
>
> -- 
> Sylvain Wallez                                  Anyware Technologies
> http://www.apache.org/~sylvain           http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>