To browse all objects and check this property individually, would take much time, wouldn’t it ?

Terracotta does not provide you with a query language (since it is not an OODBMS), so you have to use either plain Java code to do the navigation of the Java data structures (something that might require you to structure your cache in an intelligent way), or use something like Jofti (http://jofti.com/) which allows you to query objects.

But if you frequently need to do very complicated queries then this approach might not work well (however using Terracotta as a distributed cache would still be beneficial).

Hope it helps.

That could never happen with Terracotta.

Terracotta provides Virtual Memory in which objects are paged in and out on a demand basis, of course managed within ACID transactions. It is also adaptively runtime optimized based on actual usage.

This is a very much different approach than just using Prevayler (which I have used quite a lot some years ago). It is basically just the transaction log that has similarities.

Terracotta does not require Java Serialization and maintains pass-by-reference semantics, so you can work with your domain model as you would without either Terracotta or Prevayler.

Also, the state is persisted just as much (and safe) without the tx log. It is only needed if you need to have the offline RDBMS snapshot.

Terracotta does not provide you with any object schema migration tools. But it tries to have an “do no harm” approach to object updates and migrations.

This means that it allows you to add and remove fields to your objects (without shutting down the cluster, e.g. zero downtime). And as long as you do not change the type of the fields or change object hierarchies then you should be able to take down the nodes one by one and redeploy the updated application. When you start the node again it will join the cluster and have the latest state paged in before allowed to continue.

This gives you two scenarios:

– add a field to a class - in this case the field (and its values) will simply only exist on the nodes that have been updated with the new class but will eventually be present on all nodes – remove a field from a class - in this case the field will be null on all nodes that still has the old version of the class until eventually removed on all nodes

Not ideal, but I think it can get you pretty far. However, you should of course test this in the lab before trying it out on a live cluster.

Hope it helps.