cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tore Halset <hal...@pvv.ntnu.no>
Subject Re: hazelcast - serialVersionUID or not?
Date Wed, 06 Feb 2013 22:00:25 GMT
On 6. feb. 2013, at 00:11, Aristedes Maniatis <ari@maniatis.org> wrote:

> option 1: change the serial number when the classes change in some way: you get InvalidClassException.
Your code can catch this and invalidate the session.
> 
> option 2: don't change the serial number and hope that Java will unserialise your class
properly even if you have made a change to the class attributes. From my experience this tends
to work just fine if you only add attributes and breaks horribly if you change or remove any.
But from what I remember, you get a InvalidClassException anyway.
> 
> To my mind, setting the serialVersionUID to some fixed arbitrary number and never changing
it has no real downsides unless you need to detect subtle changes to the class and deliberately
throw an exception when the session is 'upgraded'. And if you use sticky sessions then the
user will be moved from the old instance to the new only when you shut down the old one (and
then not randomly back to another old instance).

Thank you. This makes a lot of sense. I was hoping for some magic inside the CayenneDataObject
to make option 2 easier.

> How are you finding hazelcast? I tinkered with Terracotta but never got it into production.

We have used hazelcast WebFilter in production for one month now and I am very happy with
it. At least so far. Before hazelcast, I tried (not in production) one other solution that
stored the sessions as blobs in the database, but was not happy with storing so many short-lived
blobs in the database. hazelcast WebFilter was also easier to deploy and easier to work with
as serialization-errors showed up earlier.

hazelcast has a auto-discovery system do find the other nodes. This did not work for us as
we run the same app in different environment for production for different customers, test,
development and so on. We ended up letting the nodes use a db-table (via CayenneDataObject)
to store the address of the different nodes using the same database. This has worked fine
so far.

Unfortunately, it was a lot of work to make the session objects serializable and make sure
less garbage are stored in the session.

 - Tore.
Mime
View raw message