Yes, you do.
The prevalent design provides ACID properties without the need for explicit transaction semantics in your code.
How is that?
DBMSs tend to support only a few basic operations: INSERT, UPDATE and DELETE, for example. Because of this limitation, you must use transaction semantics (begin - commit) to delimit the operations in every business transaction for the benefit of your DBMS. In the prevalent design, every transaction is represented as a serializable object which is atomically written to the queue (a simple log file) and processed by the system. An object, or object graph, is enough to encapsulate the complexity of any business transaction.
What about rollback?
RollbackIsNeedless.
Back to:
ObjectPrevalenceSkepticalFAQ.
I fail to see how the above description provides isolation. If two separate processes are updating the same collection of employees, one updating the salaries, the other totalling the salaries. How would the second transaction get repeatable results if it runs during or after the first transaction?
See:
WhatAreTheCodingRestrictionsMyClientClassesHaveToObey?
With regard to
ACID properties, I can see how prevayler provides Isolation and Durability, but not Atomicity and Consistency. As I understand it, Atomicity requires that either all changes to the object graph occur, or none of them occur. I can't see how
Prevayler can guarantee this. If your Command object begins modifying the persistent graph, but an unexpected exception occurs halfway through, don't the changes you have made up till the exception remain permanent and visible? Doesn't this then open you up to the possibility of leaving the object graph in an inconsistent state? --
CharlesBlaxland
What about including prevayler in a transaction w/ other resources? E.g. I want to publish a JMS, message, in a J2EE server like weblogic, and update my prevayler data in one XA transaction. Most
RDBMS's support XA, does (or will) prevayler?
Although
TwoPhaseCommitIsUnnecessary it might be useful. You can add it to the
FeatureRequests if you wish. --
KlausWuestefeld
Charles, I think the idea with
Prevayler is that your transactions are responsible for Atomicity if this property is desired (which may not be true for every transactions).
Prevayler 1.03 doesn't help you ensuring this property with a rollback facility, however you may code your transactions and domain object's methods so as to be atomic with appropriate try/catch blocks. It looks like
Prevayler 2 will have a RollbackPrevayler that will do the job automatically if a transaction raise a
RuntimeException or Error. However, it will probably be less efficient than if you're ensuring atomicity yourself.
ArnaudClere