Hi Aaron, >From the CMIS specification point of view there are no sessions. Clients and >servers are server are stateless. Therefore, server sessions cannot expire >because there aren't any. If a repository maintains a session behind the >scenes, it has to make sure that either this session never expires or the >session is transparently renewed. What you are experiencing here looks like an Alfresco bug.
As Stephan already pointed out, OpenCMIS sessions can live for a very long time. A session is tied to a user because repositories might return different repository infos and type definitions for each user. A repository might also change the language of names, display names and other properties based the on the user that is logged in. Also, the whole permission checking has to be done on the server on a per user basis. User A shouldn't see an object that user B fetched an minute ago and still is in the cache. Therefore, this data is cached inside the session and must be tied to the user. There are no user independent stable objects in CMIS. Cheers, Florian -----Original Message----- From: Klevenz, Stephan [mailto:[email protected]] Sent: Dienstag, 22. Juni 2010 09:59 To: [email protected] Subject: RE: Relationship between Cache and Session 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
