jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Pfister <dominique.pfis...@day.com>
Subject Re: Adivce about session
Date Thu, 17 Mar 2005 11:40:34 GMT
Simon Gash wrote:
> I assume that by "components that are tied to a session" you mean for
> instance the ItemManager. Am I right in saying that when you close the
> session the ItemManager (and any cache it contains will be closed as
> well ?) 

Yes, this is right. Internally, when a session is created, the following 
helper objects are created as well:

- HierarchyManagerImpl (that will help resolve paths into item IDs and 
vice versa)

- ItemManager (that will create and maintain Node and Property instances 
and guarantees uniqueness of Node and Property instances in a session, 
which is btw not required by the specification)

- LocalItemStateManager (LISM), SessionItemStateManager (SISM) and 
TransientItemStateManager (TISM)

The cooperation of these 3 ItemStateManagers is probably quite hard to 
understand, therefore let me explain it a little bit more detailed:

When items are loaded from a persistence storage, the PersistenceManager 
returns them as ItemStates (either NodeState or PropertyState). These 
ItemStates are global to the repository and cached inside the 
SharedItemStateManager (ShISM).
On session creation time, a LISM is created that effectively sits on top 
of the ShISM. Every local ItemState returned by the LISM wraps a global 
ItemState returned by the ShISM. The local ItemStates are the ones used 
in Workspace operations (such as copy or move) where changes are 
implictely saved.
In order to support transient changes (which may later be either saved 
or undone) one more layer is required which is covered by the TISM and 
SISM. As you may have guessed, the SISM sits on top of the LISM. Upon 
the first transient change to an item, a transient ItemState is created 
that wraps the local ItemState returned by the LISM.
Upon a Session.save() or Node.save() all the changes in the transient 
ItemStates are "pushed" upward to the local ItemStates. When either 
operating outside the context of a transaction or when the transaction 
is committed, the changes in the local ItemStates are again pushed 
upward to the shared ItemStates and the ShISM stores the changes inside 
the PersistenceManager.

Hope all this information is not too hard to digest ;-) Returning to the 
original question, the LISM, TISM, ItemManager and HierarchyMgrImpl (in 
the future) are all building up their own caches that you will lose on 


View raw message