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 <[email protected]> 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.
