Prevayler

Front Page :: Prevayler: "Prevayler is extremely simple, and imposes very few restrictions on your object model. The only restrictions are to make sure that transaction execution is deterministic and repeatable, so that the exact state of your business objects can be recovered from the transaction journal.
1. All modifications to your business objects must be encapsulated in transaction objects.
2. All your transactions must be completely deterministic. For example, don ' t call System.currentTimeMillis () from within a transaction (or within any business object code called indirectly by a transaction), because it will give a different answer every time the transaction is run. (If you do want to know the time, Prevayler provides an ' official ' timestamp, assigned when the transaction is first written to the journal. See the Transaction interface.)
Note that any hardware input or output is inherently nondeterministic, and therefore violates this rule. Do all I / O outside of Prevayler transactions.
3. All your transactions and business objects must be serializable, so that they can be written to the journal and snapshot. (You can also configure your own serialization mechanisms if you don ' t want to use Java serialization.)
4. Transactions can ' t carry direct object references (pointers) to business objects. This has become known as the baptism problem because it ' s a common beginner pitfall. Direct object references don ' t work because once a transaction has been serialized to the journal and then deserialized for execution its object references no longer refer to the intended objects - - any objects they may have referred to at first will have been copied by the serialization process! Therefore, a transaction must carry some kind of string or numeric identifiers for any objects it wants to refer to, and it must look up the objects when it is executed."