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
