Hi David, That all sounds like good news. So to be clear....if I have an application architecture which consists of:
* "editor" webapp - performs read/write operations * "viewer" webapp - performs only read operations ...then I can use a single shared session for all requests to "viewer" and it will automatically pick-up committed changes made in the "editor" app? The reason for the clarification is that we tried that scenario with an older version of JackRabbit late last year and encountered various InvalidItem/ItemNotExists type exceptions which we put down to accessing 'stale' cached content in the "viewer" app. As an aside, it would be interesting to here (anyones) comments on the impact of an architecture where "editor" and "viewer" are using separate but clustered JackRabbit instances? Regards, Shaun. -----Original Message----- From: David Nuescheler [mailto:[EMAIL PROTECTED] Sent: 27 March 2007 14:26 To: [email protected] Subject: Re: Profiling shows Session management to be a hotspot - session pooling etc hi shaun, the only issue that i am aware of with respect to concurrent read operations on a shared session is during shutdown under certain special conditions. generally an application should be able to concurrently read from the same session in jackrabbit and also updates to the content will be reflected in the session without calling refresh(). regards, david ___________________________________________________________ Copy addresses and emails from any email account to Yahoo! Mail - quick, easy and free. http://uk.docs.yahoo.com/trueswitch2.html
