Re: OpenCMIS: should Session extend Serializable?
FYI I just raised this enhancement as CMIS-389 [1]. Thanks for the discussion! Cheers, Peter [1] https://issues.apache.org/jira/browse/CMIS-389 On Jun 9, 2011, at 2:01 am, Florian Müller wrote: > +1 > > Florian > > On 08/06/2011 20:11, Peter Monks wrote: >> Yeah, though it sounds like it would be rare that anyone would actually >> serialize / deserialize NuxeoSession's anyway (even if they were >> serializable), so that might allow some simplifying assumptions? >> >> Opening the discussion up to the wider audience - would anyone object if I >> were to raise an enhancement request for >> org.apache.chemistry.opencmis.client.api.Session to extend >> java.io.Serializable? >> >> Cheers, >> Peter >> >> >> On Jun 8, 2011, at 9:14 am, Florent Guillaume wrote: >> >>> Hi Peter, >>> >>> Yes that would probably work. >>> The responsibility for who will be closing the connection when it's >>> been restablished during deserialization is a bit muddy, but that's >>> another concern. >>> >>> So if there's really a need to have Session be Serializable again, I >>> won't vote against it. >>> >>> Florent >>> >>> >>> On Wed, Jun 8, 2011 at 5:42 PM, Peter Monks wrote: Thanks for the clarification Florent. Question for you - if Session was Serializable, couldn't org.nuxeo.ecm.core.opencmis.impl.client.NuxeoSession hold a transient reference to the non-serializable objects, with the "connection" re-estalished automatically post-deserialization? Presumably this would require some serialization of the session parameters, but generally speaking those are fairly small / lightweight. Cheers, Peter On Jun 8, 2011, at 8:11 am, Florent Guillaume wrote: > Hi Peter, > > FYI, here's an example of non-Serializable Session implementation: > Nuxeo plugins can use OpenCMIS APIs directly in same-JVM mode (without > a networking layer being invoked), using > org.nuxeo.ecm.core.opencmis.impl.client.NuxeoSession. This > implementation of Session holds (indirectly) a reference to a > non-Serializable low-level connection-like object (think > java.sql.Connection), that by definition is not Serializable. > > Florent > > > On Thu, Jun 2, 2011 at 9:21 PM, Peter Monks wrote: >> Thanks Florian. I'm still a little confused though - if Session is not >> Serializable, how can I rely on an arbitrary Session implementation >> class being Serializable? What if someone configures my client to use >> one of these non-Chemistry Session implementations? >> >> Possible workarounds include: >> Checking whether the implementation class is an instanceof Serializable, >> and not caching it if it isn't (which implies poor performance for >> Session implementations that aren't serializable) >> Wrapping Session in a Serializable wrapper that has a transient >> reference to the Session (Session will be cached as long as it's kept in >> memory by the JVM - as soon as the cache serializes a Session for >> whatever reason, that Session will effectively become decached and incur >> the creation cost next time that user does something that requires CMIS) >> >> In the specific client I'm working on right now I can live with either >> workaround, but in general (and imho) they are both quite undesirable >> given that this is likely to be a common use case. I notice for example >> that the Liferay guys identified a need for Session caching in their >> "CMIS Document Library" implementation (see [1], in particular the >> comments). We can probably assume that either the Liferay cache doesn't >> require items to be Serializable, or they worked around it in something >> like one of the two ways described above. >> >> Thinking along different lines for a moment - why does creating a >> Session have to hit the CMIS server at all - is it to validate the >> username and password? If so, is it worth delaying that check until the >> first "real" CMIS call, thereby significantly reducing the cost of >> establishing a Session (i.e. by eliminating any RPCs to the CMIS server >> at Session creation time)? This could even be configured via a flag to >> the SessionFactory to preserve backwards compatibility. >> >> Cheers, >> Peter >> >> [1] http://www.liferay.com/web/alexander.chow/blog/-/blogs/7670631 >> >> >> >> >> On Jun 2, 2011, at 2:26 am, Florian Müller wrote: >> >>> Hi Peter, >>> >>> We had some discussions about that in the past. There are actually >>> other implementations of the OpenCMIS interfaces (not part of Apache >>> Chemistry) that can not and need not be serializable. We don't want to >>> force them to do something crazy just to implement the OpenCMIS >>> interfaces. >>>
Re: OpenCMIS: should Session extend Serializable?
+1 Florian On 08/06/2011 20:11, Peter Monks wrote: Yeah, though it sounds like it would be rare that anyone would actually serialize / deserialize NuxeoSession's anyway (even if they were serializable), so that might allow some simplifying assumptions? Opening the discussion up to the wider audience - would anyone object if I were to raise an enhancement request for org.apache.chemistry.opencmis.client.api.Session to extend java.io.Serializable? Cheers, Peter On Jun 8, 2011, at 9:14 am, Florent Guillaume wrote: Hi Peter, Yes that would probably work. The responsibility for who will be closing the connection when it's been restablished during deserialization is a bit muddy, but that's another concern. So if there's really a need to have Session be Serializable again, I won't vote against it. Florent On Wed, Jun 8, 2011 at 5:42 PM, Peter Monks wrote: Thanks for the clarification Florent. Question for you - if Session was Serializable, couldn't org.nuxeo.ecm.core.opencmis.impl.client.NuxeoSession hold a transient reference to the non-serializable objects, with the "connection" re-estalished automatically post-deserialization? Presumably this would require some serialization of the session parameters, but generally speaking those are fairly small / lightweight. Cheers, Peter On Jun 8, 2011, at 8:11 am, Florent Guillaume wrote: Hi Peter, FYI, here's an example of non-Serializable Session implementation: Nuxeo plugins can use OpenCMIS APIs directly in same-JVM mode (without a networking layer being invoked), using org.nuxeo.ecm.core.opencmis.impl.client.NuxeoSession. This implementation of Session holds (indirectly) a reference to a non-Serializable low-level connection-like object (think java.sql.Connection), that by definition is not Serializable. Florent On Thu, Jun 2, 2011 at 9:21 PM, Peter Monks wrote: Thanks Florian. I'm still a little confused though - if Session is not Serializable, how can I rely on an arbitrary Session implementation class being Serializable? What if someone configures my client to use one of these non-Chemistry Session implementations? Possible workarounds include: Checking whether the implementation class is an instanceof Serializable, and not caching it if it isn't (which implies poor performance for Session implementations that aren't serializable) Wrapping Session in a Serializable wrapper that has a transient reference to the Session (Session will be cached as long as it's kept in memory by the JVM - as soon as the cache serializes a Session for whatever reason, that Session will effectively become decached and incur the creation cost next time that user does something that requires CMIS) In the specific client I'm working on right now I can live with either workaround, but in general (and imho) they are both quite undesirable given that this is likely to be a common use case. I notice for example that the Liferay guys identified a need for Session caching in their "CMIS Document Library" implementation (see [1], in particular the comments). We can probably assume that either the Liferay cache doesn't require items to be Serializable, or they worked around it in something like one of the two ways described above. Thinking along different lines for a moment - why does creating a Session have to hit the CMIS server at all - is it to validate the username and password? If so, is it worth delaying that check until the first "real" CMIS call, thereby significantly reducing the cost of establishing a Session (i.e. by eliminating any RPCs to the CMIS server at Session creation time)? This could even be configured via a flag to the SessionFactory to preserve backwards compatibility. Cheers, Peter [1] http://www.liferay.com/web/alexander.chow/blog/-/blogs/7670631 On Jun 2, 2011, at 2:26 am, Florian Müller wrote: Hi Peter, We had some discussions about that in the past. There are actually other implementations of the OpenCMIS interfaces (not part of Apache Chemistry) that can not and need not be serializable. We don't want to force them to do something crazy just to implement the OpenCMIS interfaces. The OpenCMIS classes have been designed to be serializable from the start to support HTTP sessions. Casting to Serializable is safe now and will be safe in the future -- even though it might feel weird. What surprises me is that creating a session takes several seconds. Connecting to a Alfresco server on a local network takes about 100ms. If it takes significantly longer then there is something wrong... Florian On 01/06/2011 23:35, Peter Monks wrote: G'day everyone, Creating an org.apache.chemistry.opencmis.client.api.Session is quite an expensive operation (it typically takes several seconds), so I'm looking to cache Session objects in a per-user cache in my client app so that I don't have to recreate Sessions for every single interaction with the CMIS server. Unfortunately the cache library I'm us
Re: OpenCMIS: should Session extend Serializable?
Yeah, though it sounds like it would be rare that anyone would actually serialize / deserialize NuxeoSession's anyway (even if they were serializable), so that might allow some simplifying assumptions? Opening the discussion up to the wider audience - would anyone object if I were to raise an enhancement request for org.apache.chemistry.opencmis.client.api.Session to extend java.io.Serializable? Cheers, Peter On Jun 8, 2011, at 9:14 am, Florent Guillaume wrote: > Hi Peter, > > Yes that would probably work. > The responsibility for who will be closing the connection when it's > been restablished during deserialization is a bit muddy, but that's > another concern. > > So if there's really a need to have Session be Serializable again, I > won't vote against it. > > Florent > > > On Wed, Jun 8, 2011 at 5:42 PM, Peter Monks wrote: >> Thanks for the clarification Florent. >> >> Question for you - if Session was Serializable, couldn't >> org.nuxeo.ecm.core.opencmis.impl.client.NuxeoSession hold a transient >> reference to the non-serializable objects, with the "connection" >> re-estalished automatically post-deserialization? Presumably this would >> require some serialization of the session parameters, but generally speaking >> those are fairly small / lightweight. >> >> Cheers, >> Peter >> >> >> >> On Jun 8, 2011, at 8:11 am, Florent Guillaume wrote: >> >>> Hi Peter, >>> >>> FYI, here's an example of non-Serializable Session implementation: >>> Nuxeo plugins can use OpenCMIS APIs directly in same-JVM mode (without >>> a networking layer being invoked), using >>> org.nuxeo.ecm.core.opencmis.impl.client.NuxeoSession. This >>> implementation of Session holds (indirectly) a reference to a >>> non-Serializable low-level connection-like object (think >>> java.sql.Connection), that by definition is not Serializable. >>> >>> Florent >>> >>> >>> On Thu, Jun 2, 2011 at 9:21 PM, Peter Monks wrote: Thanks Florian. I'm still a little confused though - if Session is not Serializable, how can I rely on an arbitrary Session implementation class being Serializable? What if someone configures my client to use one of these non-Chemistry Session implementations? Possible workarounds include: Checking whether the implementation class is an instanceof Serializable, and not caching it if it isn't (which implies poor performance for Session implementations that aren't serializable) Wrapping Session in a Serializable wrapper that has a transient reference to the Session (Session will be cached as long as it's kept in memory by the JVM - as soon as the cache serializes a Session for whatever reason, that Session will effectively become decached and incur the creation cost next time that user does something that requires CMIS) In the specific client I'm working on right now I can live with either workaround, but in general (and imho) they are both quite undesirable given that this is likely to be a common use case. I notice for example that the Liferay guys identified a need for Session caching in their "CMIS Document Library" implementation (see [1], in particular the comments). We can probably assume that either the Liferay cache doesn't require items to be Serializable, or they worked around it in something like one of the two ways described above. Thinking along different lines for a moment - why does creating a Session have to hit the CMIS server at all - is it to validate the username and password? If so, is it worth delaying that check until the first "real" CMIS call, thereby significantly reducing the cost of establishing a Session (i.e. by eliminating any RPCs to the CMIS server at Session creation time)? This could even be configured via a flag to the SessionFactory to preserve backwards compatibility. Cheers, Peter [1] http://www.liferay.com/web/alexander.chow/blog/-/blogs/7670631 On Jun 2, 2011, at 2:26 am, Florian Müller wrote: > Hi Peter, > > We had some discussions about that in the past. There are actually other > implementations of the OpenCMIS interfaces (not part of Apache Chemistry) > that can not and need not be serializable. We don't want to force them to > do something crazy just to implement the OpenCMIS interfaces. > > The OpenCMIS classes have been designed to be serializable from the start > to support HTTP sessions. Casting to Serializable is safe now and will be > safe in the future -- even though it might feel weird. > > What surprises me is that creating a session takes several seconds. > Connecting to a Alfresco server on a local network takes about 100ms. If > it takes significantly longer then there is something wrong... > > > Florian > > >>
Re: OpenCMIS: should Session extend Serializable?
Hi Peter, Yes that would probably work. The responsibility for who will be closing the connection when it's been restablished during deserialization is a bit muddy, but that's another concern. So if there's really a need to have Session be Serializable again, I won't vote against it. Florent On Wed, Jun 8, 2011 at 5:42 PM, Peter Monks wrote: > Thanks for the clarification Florent. > > Question for you - if Session was Serializable, couldn't > org.nuxeo.ecm.core.opencmis.impl.client.NuxeoSession hold a transient > reference to the non-serializable objects, with the "connection" > re-estalished automatically post-deserialization? Presumably this would > require some serialization of the session parameters, but generally speaking > those are fairly small / lightweight. > > Cheers, > Peter > > > > On Jun 8, 2011, at 8:11 am, Florent Guillaume wrote: > >> Hi Peter, >> >> FYI, here's an example of non-Serializable Session implementation: >> Nuxeo plugins can use OpenCMIS APIs directly in same-JVM mode (without >> a networking layer being invoked), using >> org.nuxeo.ecm.core.opencmis.impl.client.NuxeoSession. This >> implementation of Session holds (indirectly) a reference to a >> non-Serializable low-level connection-like object (think >> java.sql.Connection), that by definition is not Serializable. >> >> Florent >> >> >> On Thu, Jun 2, 2011 at 9:21 PM, Peter Monks wrote: >>> Thanks Florian. I'm still a little confused though - if Session is not >>> Serializable, how can I rely on an arbitrary Session implementation class >>> being Serializable? What if someone configures my client to use one of >>> these non-Chemistry Session implementations? >>> >>> Possible workarounds include: >>> Checking whether the implementation class is an instanceof Serializable, >>> and not caching it if it isn't (which implies poor performance for Session >>> implementations that aren't serializable) >>> Wrapping Session in a Serializable wrapper that has a transient reference >>> to the Session (Session will be cached as long as it's kept in memory by >>> the JVM - as soon as the cache serializes a Session for whatever reason, >>> that Session will effectively become decached and incur the creation cost >>> next time that user does something that requires CMIS) >>> >>> In the specific client I'm working on right now I can live with either >>> workaround, but in general (and imho) they are both quite undesirable given >>> that this is likely to be a common use case. I notice for example that the >>> Liferay guys identified a need for Session caching in their "CMIS Document >>> Library" implementation (see [1], in particular the comments). We can >>> probably assume that either the Liferay cache doesn't require items to be >>> Serializable, or they worked around it in something like one of the two >>> ways described above. >>> >>> Thinking along different lines for a moment - why does creating a Session >>> have to hit the CMIS server at all - is it to validate the username and >>> password? If so, is it worth delaying that check until the first "real" >>> CMIS call, thereby significantly reducing the cost of establishing a >>> Session (i.e. by eliminating any RPCs to the CMIS server at Session >>> creation time)? This could even be configured via a flag to the >>> SessionFactory to preserve backwards compatibility. >>> >>> Cheers, >>> Peter >>> >>> [1] http://www.liferay.com/web/alexander.chow/blog/-/blogs/7670631 >>> >>> >>> >>> >>> On Jun 2, 2011, at 2:26 am, Florian Müller wrote: >>> Hi Peter, We had some discussions about that in the past. There are actually other implementations of the OpenCMIS interfaces (not part of Apache Chemistry) that can not and need not be serializable. We don't want to force them to do something crazy just to implement the OpenCMIS interfaces. The OpenCMIS classes have been designed to be serializable from the start to support HTTP sessions. Casting to Serializable is safe now and will be safe in the future -- even though it might feel weird. What surprises me is that creating a session takes several seconds. Connecting to a Alfresco server on a local network takes about 100ms. If it takes significantly longer then there is something wrong... Florian On 01/06/2011 23:35, Peter Monks wrote: > G'day everyone, > > Creating an org.apache.chemistry.opencmis.client.api.Session is quite an > expensive operation (it typically takes several seconds), so I'm looking > to cache Session objects in a per-user cache in my client app so that I > don't have to recreate Sessions for every single interaction with the > CMIS server. > > Unfortunately the cache library I'm using requires that cached objects > implement java.io.Serializable, which Session does not. However the > default implementation class > (org.apache.c
Re: OpenCMIS: should Session extend Serializable?
Thanks for the clarification Florent. Question for you - if Session was Serializable, couldn't org.nuxeo.ecm.core.opencmis.impl.client.NuxeoSession hold a transient reference to the non-serializable objects, with the "connection" re-estalished automatically post-deserialization? Presumably this would require some serialization of the session parameters, but generally speaking those are fairly small / lightweight. Cheers, Peter On Jun 8, 2011, at 8:11 am, Florent Guillaume wrote: > Hi Peter, > > FYI, here's an example of non-Serializable Session implementation: > Nuxeo plugins can use OpenCMIS APIs directly in same-JVM mode (without > a networking layer being invoked), using > org.nuxeo.ecm.core.opencmis.impl.client.NuxeoSession. This > implementation of Session holds (indirectly) a reference to a > non-Serializable low-level connection-like object (think > java.sql.Connection), that by definition is not Serializable. > > Florent > > > On Thu, Jun 2, 2011 at 9:21 PM, Peter Monks wrote: >> Thanks Florian. I'm still a little confused though - if Session is not >> Serializable, how can I rely on an arbitrary Session implementation class >> being Serializable? What if someone configures my client to use one of >> these non-Chemistry Session implementations? >> >> Possible workarounds include: >> Checking whether the implementation class is an instanceof Serializable, and >> not caching it if it isn't (which implies poor performance for Session >> implementations that aren't serializable) >> Wrapping Session in a Serializable wrapper that has a transient reference to >> the Session (Session will be cached as long as it's kept in memory by the >> JVM - as soon as the cache serializes a Session for whatever reason, that >> Session will effectively become decached and incur the creation cost next >> time that user does something that requires CMIS) >> >> In the specific client I'm working on right now I can live with either >> workaround, but in general (and imho) they are both quite undesirable given >> that this is likely to be a common use case. I notice for example that the >> Liferay guys identified a need for Session caching in their "CMIS Document >> Library" implementation (see [1], in particular the comments). We can >> probably assume that either the Liferay cache doesn't require items to be >> Serializable, or they worked around it in something like one of the two ways >> described above. >> >> Thinking along different lines for a moment - why does creating a Session >> have to hit the CMIS server at all - is it to validate the username and >> password? If so, is it worth delaying that check until the first "real" >> CMIS call, thereby significantly reducing the cost of establishing a Session >> (i.e. by eliminating any RPCs to the CMIS server at Session creation time)? >> This could even be configured via a flag to the SessionFactory to preserve >> backwards compatibility. >> >> Cheers, >> Peter >> >> [1] http://www.liferay.com/web/alexander.chow/blog/-/blogs/7670631 >> >> >> >> >> On Jun 2, 2011, at 2:26 am, Florian Müller wrote: >> >>> Hi Peter, >>> >>> We had some discussions about that in the past. There are actually other >>> implementations of the OpenCMIS interfaces (not part of Apache Chemistry) >>> that can not and need not be serializable. We don't want to force them to >>> do something crazy just to implement the OpenCMIS interfaces. >>> >>> The OpenCMIS classes have been designed to be serializable from the start >>> to support HTTP sessions. Casting to Serializable is safe now and will be >>> safe in the future -- even though it might feel weird. >>> >>> What surprises me is that creating a session takes several seconds. >>> Connecting to a Alfresco server on a local network takes about 100ms. If it >>> takes significantly longer then there is something wrong... >>> >>> >>> Florian >>> >>> >>> On 01/06/2011 23:35, Peter Monks wrote: G'day everyone, Creating an org.apache.chemistry.opencmis.client.api.Session is quite an expensive operation (it typically takes several seconds), so I'm looking to cache Session objects in a per-user cache in my client app so that I don't have to recreate Sessions for every single interaction with the CMIS server. Unfortunately the cache library I'm using requires that cached objects implement java.io.Serializable, which Session does not. However the default implementation class (org.apache.chemistry.opencmis.client.runtime.SessionImpl) does in fact implement Serializable, allowing me the workaround of casting the Session object to Serializable prior to adding to the cache. I'm not particularly comfortable with this approach however, given that this seems to be an implementation detail and not officially part of the contract for Sessions. Is there a compelling reason that Session doesn't i
Re: OpenCMIS: should Session extend Serializable?
Hi Peter, FYI, here's an example of non-Serializable Session implementation: Nuxeo plugins can use OpenCMIS APIs directly in same-JVM mode (without a networking layer being invoked), using org.nuxeo.ecm.core.opencmis.impl.client.NuxeoSession. This implementation of Session holds (indirectly) a reference to a non-Serializable low-level connection-like object (think java.sql.Connection), that by definition is not Serializable. Florent On Thu, Jun 2, 2011 at 9:21 PM, Peter Monks wrote: > Thanks Florian. I'm still a little confused though - if Session is not > Serializable, how can I rely on an arbitrary Session implementation class > being Serializable? What if someone configures my client to use one of these > non-Chemistry Session implementations? > > Possible workarounds include: > Checking whether the implementation class is an instanceof Serializable, and > not caching it if it isn't (which implies poor performance for Session > implementations that aren't serializable) > Wrapping Session in a Serializable wrapper that has a transient reference to > the Session (Session will be cached as long as it's kept in memory by the JVM > - as soon as the cache serializes a Session for whatever reason, that Session > will effectively become decached and incur the creation cost next time that > user does something that requires CMIS) > > In the specific client I'm working on right now I can live with either > workaround, but in general (and imho) they are both quite undesirable given > that this is likely to be a common use case. I notice for example that the > Liferay guys identified a need for Session caching in their "CMIS Document > Library" implementation (see [1], in particular the comments). We can > probably assume that either the Liferay cache doesn't require items to be > Serializable, or they worked around it in something like one of the two ways > described above. > > Thinking along different lines for a moment - why does creating a Session > have to hit the CMIS server at all - is it to validate the username and > password? If so, is it worth delaying that check until the first "real" CMIS > call, thereby significantly reducing the cost of establishing a Session (i.e. > by eliminating any RPCs to the CMIS server at Session creation time)? This > could even be configured via a flag to the SessionFactory to preserve > backwards compatibility. > > Cheers, > Peter > > [1] http://www.liferay.com/web/alexander.chow/blog/-/blogs/7670631 > > > > > On Jun 2, 2011, at 2:26 am, Florian Müller wrote: > >> Hi Peter, >> >> We had some discussions about that in the past. There are actually other >> implementations of the OpenCMIS interfaces (not part of Apache Chemistry) >> that can not and need not be serializable. We don't want to force them to do >> something crazy just to implement the OpenCMIS interfaces. >> >> The OpenCMIS classes have been designed to be serializable from the start to >> support HTTP sessions. Casting to Serializable is safe now and will be safe >> in the future -- even though it might feel weird. >> >> What surprises me is that creating a session takes several seconds. >> Connecting to a Alfresco server on a local network takes about 100ms. If it >> takes significantly longer then there is something wrong... >> >> >> Florian >> >> >> On 01/06/2011 23:35, Peter Monks wrote: >>> G'day everyone, >>> >>> Creating an org.apache.chemistry.opencmis.client.api.Session is quite an >>> expensive operation (it typically takes several seconds), so I'm looking to >>> cache Session objects in a per-user cache in my client app so that I don't >>> have to recreate Sessions for every single interaction with the CMIS server. >>> >>> Unfortunately the cache library I'm using requires that cached objects >>> implement java.io.Serializable, which Session does not. However the >>> default implementation class >>> (org.apache.chemistry.opencmis.client.runtime.SessionImpl) does in fact >>> implement Serializable, allowing me the workaround of casting the Session >>> object to Serializable prior to adding to the cache. I'm not particularly >>> comfortable with this approach however, given that this seems to be an >>> implementation detail and not officially part of the contract for Sessions. >>> >>> Is there a compelling reason that Session doesn't implement Serializable? >>> Is this something that could be added (noting that this change is backwards >>> compatible)? >>> >>> Thanks in advance, >>> Peter >>> >>> >> > > -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
Re: OpenCMIS: should Session extend Serializable?
Thanks Florian. I'm still a little confused though - if Session is not Serializable, how can I rely on an arbitrary Session implementation class being Serializable? What if someone configures my client to use one of these non-Chemistry Session implementations? Possible workarounds include: Checking whether the implementation class is an instanceof Serializable, and not caching it if it isn't (which implies poor performance for Session implementations that aren't serializable) Wrapping Session in a Serializable wrapper that has a transient reference to the Session (Session will be cached as long as it's kept in memory by the JVM - as soon as the cache serializes a Session for whatever reason, that Session will effectively become decached and incur the creation cost next time that user does something that requires CMIS) In the specific client I'm working on right now I can live with either workaround, but in general (and imho) they are both quite undesirable given that this is likely to be a common use case. I notice for example that the Liferay guys identified a need for Session caching in their "CMIS Document Library" implementation (see [1], in particular the comments). We can probably assume that either the Liferay cache doesn't require items to be Serializable, or they worked around it in something like one of the two ways described above. Thinking along different lines for a moment - why does creating a Session have to hit the CMIS server at all - is it to validate the username and password? If so, is it worth delaying that check until the first "real" CMIS call, thereby significantly reducing the cost of establishing a Session (i.e. by eliminating any RPCs to the CMIS server at Session creation time)? This could even be configured via a flag to the SessionFactory to preserve backwards compatibility. Cheers, Peter [1] http://www.liferay.com/web/alexander.chow/blog/-/blogs/7670631 On Jun 2, 2011, at 2:26 am, Florian Müller wrote: > Hi Peter, > > We had some discussions about that in the past. There are actually other > implementations of the OpenCMIS interfaces (not part of Apache Chemistry) > that can not and need not be serializable. We don't want to force them to do > something crazy just to implement the OpenCMIS interfaces. > > The OpenCMIS classes have been designed to be serializable from the start to > support HTTP sessions. Casting to Serializable is safe now and will be safe > in the future -- even though it might feel weird. > > What surprises me is that creating a session takes several seconds. > Connecting to a Alfresco server on a local network takes about 100ms. If it > takes significantly longer then there is something wrong... > > > Florian > > > On 01/06/2011 23:35, Peter Monks wrote: >> G'day everyone, >> >> Creating an org.apache.chemistry.opencmis.client.api.Session is quite an >> expensive operation (it typically takes several seconds), so I'm looking to >> cache Session objects in a per-user cache in my client app so that I don't >> have to recreate Sessions for every single interaction with the CMIS server. >> >> Unfortunately the cache library I'm using requires that cached objects >> implement java.io.Serializable, which Session does not. However the default >> implementation class >> (org.apache.chemistry.opencmis.client.runtime.SessionImpl) does in fact >> implement Serializable, allowing me the workaround of casting the Session >> object to Serializable prior to adding to the cache. I'm not particularly >> comfortable with this approach however, given that this seems to be an >> implementation detail and not officially part of the contract for Sessions. >> >> Is there a compelling reason that Session doesn't implement Serializable? >> Is this something that could be added (noting that this change is backwards >> compatible)? >> >> Thanks in advance, >> Peter >> >> >
Re: OpenCMIS: should Session extend Serializable?
Hi Peter, We had some discussions about that in the past. There are actually other implementations of the OpenCMIS interfaces (not part of Apache Chemistry) that can not and need not be serializable. We don't want to force them to do something crazy just to implement the OpenCMIS interfaces. The OpenCMIS classes have been designed to be serializable from the start to support HTTP sessions. Casting to Serializable is safe now and will be safe in the future -- even though it might feel weird. What surprises me is that creating a session takes several seconds. Connecting to a Alfresco server on a local network takes about 100ms. If it takes significantly longer then there is something wrong... Florian On 01/06/2011 23:35, Peter Monks wrote: G'day everyone, Creating an org.apache.chemistry.opencmis.client.api.Session is quite an expensive operation (it typically takes several seconds), so I'm looking to cache Session objects in a per-user cache in my client app so that I don't have to recreate Sessions for every single interaction with the CMIS server. Unfortunately the cache library I'm using requires that cached objects implement java.io.Serializable, which Session does not. However the default implementation class (org.apache.chemistry.opencmis.client.runtime.SessionImpl) does in fact implement Serializable, allowing me the workaround of casting the Session object to Serializable prior to adding to the cache. I'm not particularly comfortable with this approach however, given that this seems to be an implementation detail and not officially part of the contract for Sessions. Is there a compelling reason that Session doesn't implement Serializable? Is this something that could be added (noting that this change is backwards compatible)? Thanks in advance, Peter
OpenCMIS: should Session extend Serializable?
G'day everyone, Creating an org.apache.chemistry.opencmis.client.api.Session is quite an expensive operation (it typically takes several seconds), so I'm looking to cache Session objects in a per-user cache in my client app so that I don't have to recreate Sessions for every single interaction with the CMIS server. Unfortunately the cache library I'm using requires that cached objects implement java.io.Serializable, which Session does not. However the default implementation class (org.apache.chemistry.opencmis.client.runtime.SessionImpl) does in fact implement Serializable, allowing me the workaround of casting the Session object to Serializable prior to adding to the cache. I'm not particularly comfortable with this approach however, given that this seems to be an implementation detail and not officially part of the contract for Sessions. Is there a compelling reason that Session doesn't implement Serializable? Is this something that could be added (noting that this change is backwards compatible)? Thanks in advance, Peter
