cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <mgen...@masslight.net>
Subject Re: hazelcast - serialVersionUID or not?
Date Wed, 06 Feb 2013 16:46:35 GMT
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 <halset@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.

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