chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Monks <pmo...@alfresco.com>
Subject Re: OpenCMIS: should Session extend Serializable?
Date Thu, 02 Jun 2011 19:21:39 GMT
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
>> 
>> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message