hazelcast - serialVersionUID or not?

[Tore Halset <ha...@pvv.ntnu.no>]

Hello.

We have started to use hazelcast to serialize and persist the http sessions across our servers. To make this work, we had to make sure that everything we store in the session is Serializable. We also did some tricks to make sure hazelcast does not share the session between environments (production versus test..). A modern web app should probably not use sessions at all, but this is a old big one.

A nice bonus effect is that we now can upgrade our application (using jenkins) without anyone being logged out of their session. We use sticky session with fallback, so the user switch to a working server when their server is being upgraded. So far so good.

Should we add serialVersionUID to our CayenneDataObject subclasses or not? So far, I have added it to some of the CDOs.. It is working fine, but upgrades to a new version that might change the generated serialVersionUID might lead to java.io.InvalidClassException ... local class incompatible error.

So, what is best practice for serializing CDOs across changes to the class?

Regards,
Tore Halset.

one-to-many

[emeka okafor <em...@yahoo.com>]

I am working on a desktop app at the moment and I have to use either h2 or derby as DB. Now I don't know what I am doing wrong but I can't seem to be able to delete elements from a one-to-many relations, no matter whether it is the "toOne"    or the "toMany". I get a constraint violation error. Has anybody had the same problems before? I hope that it is not related to the lack of "deferred constraint checking" in both databases. Anyway, any idea what might be wrong or how to solve it?
To illustrate my point, this is the simplest case of one-to-many anyone could come up with:

       <obj-relationship name="children" source="Father" target="Child" deleteRule="Cascade" db-relationship-path="children"/> 
       <obj-relationship name="father" source="Child" target="Father" deleteRule="Nullify" db-relationship-path="father"/>

I cannot delete neither father nor children whithout getting a constraint violation error.

Thanks.

Re: hazelcast - serialVersionUID or not?

[Michael Gentry <mg...@masslight.net>]

Hi Tore,

If your schema hasn't changed, the version is effectively the same.  If
your schema *has* changed, though, you probably need to update the
serialVersionUID
or have some other mechanism to handle the schema/class changes.

I keep planning on investigating failover/replication strategies, but
haven't gotten to it yet.  Sorry I can't provide concrete details for
handling the harder problem (schema changes) with no downtime.

mrg


On Tue, Feb 5, 2013 at 10:19 AM, Tore Halset <ha...@pvv.ntnu.no> wrote:

> Hello.
>
> We have started to use hazelcast to serialize and persist the http
> sessions across our servers. To make this work, we had to make sure that
> everything we store in the session is Serializable. We also did some tricks
> to make sure hazelcast does not share the session between environments
> (production versus test..). A modern web app should probably not use
> sessions at all, but this is a old big one.
>
> A nice bonus effect is that we now can upgrade our application (using
> jenkins) without anyone being logged out of their session. We use sticky
> session with fallback, so the user switch to a working server when their
> server is being upgraded. So far so good.
>
> Should we add serialVersionUID to our CayenneDataObject subclasses or not?
> So far, I have added it to some of the CDOs.. It is working fine, but
> upgrades to a new version that might change the generated serialVersionUID
> might lead to java.io.InvalidClassException ... local class incompatible
> error.
>
> So, what is best practice for serializing CDOs across changes to the class?
>
> Regards,
> Tore Halset.

Re: hazelcast - serialVersionUID or not?

[Tore Halset <ha...@pvv.ntnu.no>]

On 6. feb. 2013, at 00:11, Aristedes Maniatis <ar...@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.

Re: hazelcast - serialVersionUID or not?

[Aristedes Maniatis <ar...@maniatis.org>]

On 6/02/13 2:19am, Tore Halset wrote:
> Should we add serialVersionUID to our CayenneDataObject subclasses or not? So far, I have added it to some of the CDOs.. It is working fine, but upgrades to a new version that might change the generated serialVersionUID might lead to java.io.InvalidClassException ... local class incompatible error.
>
> So, what is best practice for serializing CDOs across changes to the class?


Doesn't this just depend on which error you'd like to get:

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).


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

Ari


-- 
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A