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