Java Reference
In-Depth Information
modules, perhaps as part of a refactoring, often requires
changing the transaction code. For example, if module A
begins a database transaction, updates the database and then
commits the transaction and module B does the same,
consider what happens when you try to use both from module
C. Module C, which is performing what is a single logical
action, is actually causing two independent transactions to
occur. If module B were to fail during an operation, module
A's work is still committed. This is not the desired behavior.
If, instead, module A and module B both used CMTs, module
C can also start a CMT (typically implicitly via the
deployment descriptor) and the work in modules A and B will
be implicitly part of the same unit of work without any need
for complex rework.
If your application needs to access multiple resources as part
of the same operation, you need two-phase commit
transactions. For example, if a message is removed from a
JMS queue and then a record is updated in a database based
on that message, it is important that either both operations
occur -- or that neither occurs. If the message was removed
from the queue and then the system failed without updating
the database, this system is inconsistent. Serious customer and
business implications result from inconsistent states.
We occasionally see client applications trying to implement
their own solutions. Perhaps the application code will try to
"undo" the queue operation if the database update fails. We
don't recommend this. The implementation is much more
complex than you initially think and there are many corner
cases (imagine what happens if the application crashes in the
middle of this). Instead, use two-phase commit transactions.
If you use CMT and access to two-phase commit capable
Search WWH ::




Custom Search