Hi Aron, In theory there is no assumption about the lifetime of the session. It can be short, that means opening a session for each request, it can be bound to a HTTP session or it should also be possible to serialize the session and keep it for a very long time. Finally the session lifetime is controlled by the calling application. Actually the session consists of the bound repository, the cached items and the user credentials.
Because of the stateless behavior of the SOAP/REST communication user credentials are always passed to the protocol layer. A user session timeout at the backend should be independent of that. Regards, Stephan BTW, the use case for a request based session are composite applications that consist of independent parts assembled together. The request based session avoids that each part has to open its own session. -----Original Message----- From: Aaron Korver [mailto:[email protected]] Sent: Montag, 21. Juni 2010 23:39 To: [email protected] Subject: Relationship between Cache and Session Hello again Chemistry devs, I have an observation and a question for ya'll. Looking at the PersistantSessionImpl class, there is a Cache object in there. This would imply to me then that each session has its own cache. And looking at the constructor for the PersistantSessionImpl shows that this is true, since CacheImpl.newInstance() is called. The session seems to also be highly dependent upon the logon token for the user. I haven't tracked this down yet, but what I'm seeing is that a session is created, and can be used for about 5-10 min. After this amount of time has elapsed, the SOAP logon token is no longer valid and I get an exception back from the Alfresco CMIS implementation. I apologize for not having the exact stack trace at the moment, I can get it upon request though. This would seem to indicate that the appropriate pattern would be to create a new session per request? Since long running sessions look like they time out. I'm also thinking that this is correct since each session is tied to a specific user. If the assumption of short lived Sessions is correct, then I fail to see an advantage of using a Cache, since each Session will be a fresh instance. If the cache was decoupled from the Session then this would be advantageous for some types of stable objects (repositories, folders, etc). If my assumption is incorrect, and Sessions are assumed to be long lived objects, how does one update the timestamp on the Session to prevent the SOAP login from expiring? Or maybe this is a problem that is specific to Alfresco and I'm barking up the wrong tree? :-) Thanks for your input, Aaron Korver
