You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by Aaron Korver <aa...@gmail.com> on 2010/06/21 23:38:48 UTC
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
Re: Relationship between Cache and Session
Posted by David Caruana <da...@alfresco.com>.
> 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:stephan.klevenz@sap.com]
> Sent: Dienstag, 22. Juni 2010 09:59
> To: chemistry-dev@incubator.apache.org
> 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:aaron.korver@gmail.com]
> Sent: Montag, 21. Juni 2010 23:39
> To: chemistry-dev@incubator.apache.org
> 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
RE: Relationship between Cache and Session
Posted by Florian Müller <fm...@opentext.com>.
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:stephan.klevenz@sap.com]
Sent: Dienstag, 22. Juni 2010 09:59
To: chemistry-dev@incubator.apache.org
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:aaron.korver@gmail.com]
Sent: Montag, 21. Juni 2010 23:39
To: chemistry-dev@incubator.apache.org
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
RE: Relationship between Cache and Session
Posted by "Klevenz, Stephan" <st...@sap.com>.
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:aaron.korver@gmail.com]
Sent: Montag, 21. Juni 2010 23:39
To: chemistry-dev@incubator.apache.org
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