jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Gash" <Simon.G...@gossinteractive.com>
Subject RE: Adivce about session - Bayesian Filter detected spam
Date Thu, 17 Mar 2005 12:44:25 GMT
Well I don't think I could have asked for a more extensive reply,
fantastic thanks.

My final question would be about the link between a user and a session.
If I could leave the 'session' object up and running on a web box
servicing a huge number of requests I would be able to scale the
solution (as all the caches are full of juicy data servicing millions of
requests). The bit I don't understand is how, many users can utilize the
same session without causing authorisation problems. I noticed that on
log out the ItemManager is destroyed (at one point I thought users just
logged in and out of an existing session).

Many thanks for your help with this guys...

 

-----Original Message-----
From: Dominique Pfister [mailto:dominique.pfister@day.com] 
Sent: 17 March 2005 11:41
To: jackrabbit-dev@incubator.apache.org
Subject: Re: Adivce about session - Bayesian Filter detected spam

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
Session.logout.

Regards
Dominique

This email contains proprietary information, some or all of which may be legally privileged.
It is for the intended recipient only. If an addressing or transmission error has misdirected
this email, please notify the author by replying to this email. If you are not the intended
recipient you may not use, disclose, distribute, copy, print or rely on this email. 

Email transmission cannot be guaranteed to be secure or error free, as information may be
intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. This
email and any files attached to it have been checked with virus detection software before
transmission. You should nonetheless carry out your own virus check before opening any attachment.
GOSS Interactive Ltd accepts no liability for any loss or damage that may be caused by software
viruses.

GOSS - Ranked 4th in the Deloitte Technology Fast 50 Awards 2004 and 88th in the Deloitte
Technology Fast 500 EMEA.


Mime
View raw message