when i changes a class without deleting the objectdb folder terracotta crashed. that is how i learned i should not change managed objects while terracotta is running, or when persistence mode is in use.
what does it mean on upgrading my code in production? say i have 3 nodes and i wand to upgrade the classes one node at a time. i take the first one down and upgrade the classes. then i bring it up and take the next one down.. but, terracotta would crash by that time, as the class is different from the one in the objectdb..
You should be able to do this. We support various types of class changes - the only thing you cannot do is to change the type of a field already stored in the objectdb to an incompatible type - say from Foo to Bar.
If you can confirm that you cannot do an upgrade using the latest software - 2.4.0 - then please file a bug if you have been able to reproduce the problem.
well, this is exactly what i did.
i changed a class (internally) without changing it's type and then terracotta crashed.
so you say that i should be able to change classes implementetion and introduce new types without loosing session state held in database?
what are the limitations?
That's correct the product supports changing versions of a class. If you ran into an issue then it is a bug and if you can reproduce it then please file a bug and we will fix it.
The limitations are:
- if you change a type of a field in a class to an imcompatible type, say you have Foo myField. If you change it to be Bar myField then the class will not load. The fix for this is on the roadmap, to enable you to implement some type of conversion routine.
- if you remove a field, it will still live in the Terracotta server - but your application cannot access it since the class does not define it.
- if you add a field - it will be null initially so your application must be able to initialize it (you can use the onLoad bean shell script to initialize it the same way as you would for a transient field)