Authors: cv and Jon Tirsen
General Restrictions
Prevayler keeps your whole object graph in RAM while your application is running, so you must have enough RAM available for all your objects, plus other applications. Be sure to take that into account before starting to create a prevalent system.
Coding Restrictions for Business Objects
Your business objects must be always serializable (that is, they must implement either java.io.Serializable or java.io.Externalizable), and they must be deterministic.
Being deterministic also implies that your business objects should not access any external resources (files, databases, message queues, etc). Instead, you should access external resources using through your Client objects, which pump data inside Transaction objects, and then into your system.
Coding Restrictions for Client Objects
Every change to your business objects made by the client objects must be made through a Transaction. Transactions implement either org.prevayler.Transaction or org.prevayler.TransactionWithQuery and must also be serializable.
Coding Restrictions for Transaction objects
Due to Java serialization's mechanism, you cannot hold references to your business objects inside your Transaction class, or you're going to end up with a malfunctioning system – and some hard to catch bugs, too. This is referred by the Prevayler team as "The Baptism Problem", as most new Prevayler users end up having it.
Transaction objects also must be deterministic, and the restrictions for business objects regarding this subject also apply.
