Mailing-List: contact dev-help@chemistry.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@chemistry.apache.org
Received-SPF: pass (nike.apache.org: domain of pmonks@alfresco.com designates
 207.126.144.125 as permitted sender)
Subject: Re: OpenCMIS: should Session extend Serializable?
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-51-170301723
From: Peter Monks <pmonks@alfresco.com>
In-Reply-To: <4DE75745.4010206@alfresco.com>
Date: Thu, 2 Jun 2011 12:21:39 -0700
Cc: dev@chemistry.apache.org
Message-Id: <9CE042C9-2E89-4D32-BD98-54085E5AD28C@alfresco.com>
References: <1C39FC46-5696-4FF5-BAF6-45362974AF91@alfresco.com>
 <4DE75745.4010206@alfresco.com>
To: =?iso-8859-1?Q?Florian_M=FCller?= <florian.mueller@alfresco.com>

--Apple-Mail-51-170301723
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

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
=20
=20


On Jun 2, 2011, at 2:26 am, Florian M=FCller wrote:

> Hi Peter,
>=20
> 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.
>=20
> 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.
>=20
> 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...
>=20
>=20
> Florian
>=20
>=20
> On 01/06/2011 23:35, Peter Monks wrote:
>> G'day everyone,
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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)?
>>=20
>> Thanks in advance,
>> Peter
>>=20
>>=20
>=20


--Apple-Mail-51-170301723--