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 <[email protected]> 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
