> What you are experiencing here looks like an Alfresco bug. It does seem like a bug - thank you for bringing to our attention.
Dave On 22 Jun 2010, at 09:45, Florian Müller wrote: > 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
