# Fallacy 2.5: Concurrency, Persistence, Transactions and Java EE

I got some interesting comments for my last entry "Fallacy 2: EJBs are too complex, POJOs are easier". An interesting conclusion: I got some interesting comments about the transactionality, but no one was against the fallacy :-). In my opinion it is crucial in a transaction to receive *always* the same instance of the persistence entity. This is indirectly defined in the ACID.From wikipedia: "...Atomicity
refers to the ability of the DBMS to guarantee that either all of the
tasks of a transaction are performed or none of them are. The transfer
of funds can be completed or it can fail for a multitude of reasons,
but atomicity guarantees that one account won't be debited if the other
is not credited as well.
Consistency
refers to the database being in a legal state when the transaction
begins and when it ends. This means that a transaction can't break the
rules, or integrity constraints, of the database. If an
integrity constraint states that all accounts must have a positive
balance, then any transaction violating this rule will be aborted.
Isolation
refers to the ability of the application to make operations in a
transaction appear isolated from all other operations. This means that
no operation outside the transaction can ever see the data in an
intermediate state; a bank manager can see the transferred funds on one
account or the other, but never on both—even if she ran her query while
the transfer was still being processed. More formally, isolation means
the transaction history (or schedule) is serializable. For performance reasons, this ability is the most often relaxed constraint. See the isolation article for more details.
Durability
refers to the guarantee that once the user has been notified of
success, the transaction will persist, and not be undone. This means it
will survive system failure, and that the database system has checked the integrity constraints and won't need to abort the transaction. Typically, all transactions are written into a log
that can be played back to recreate the system to its state right
before the failure. A transaction can only be deemed committed after it
is safely in the log.".Having a several copies of one dataset (a persistence object) will break the Consistency rule from ACID. Your data in a transaction can become inconsistent. The last update of the VO (it is nothing else then) will override already done changes with old data (attributes). This is similar to the Ruby On Rails problem.So having different copies of a transactional, persistent object is transactional, but the consistency of a transaction cannot be assured -> so the transaction is worthless. This becomes only a problem in more complex projects with more developer involved. Very simple applications will probably do not have such consistency problems. But nowadays it is really hard to find very simple applications  - they also tend often to grow :-).