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
