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:[EMAIL PROTECTED] Sent: 17 March 2005 11:41 To: [email protected] 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.
