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
