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<[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 >> >
