Java Reference
In-Depth Information
the cheese bundle or any of its dependencies in the
OSG
i console using the
stop
com-
mand, the cheese offer will vanish again. The authors can stop and start bundles and
watch application behavior change a lot before they get bored of the trick.)
3.3
Transactions—the secret ingredient
Working through the inventory example, you'll have noticed a few references to trans-
actions,
XA
, and
JTA
. You've written the
Inventory
class so it has full container-managed
transaction support. Does it need this elaborate transaction infrastructure for its simple
database reads and writes? Well, possibly not. But container-managed
JPA
(with or with-
out
OSG
i) always requires a transaction to be present to update a database, so doing work
without transactions means moving to unmanaged or application-managed
JPA
.
Even in the unmanaged case, it's difficult to do anything with databases
without
get-
ting transactions involved. We don't recommend you try it, but rewriting the example
so that it doesn't use
XA
and
JTA
requires
more
transaction-related metadata and an
alarming quantity of transaction-related code. Getting it to work at all requires a
pretty solid knowledge of transactions. Luckily, you can usually rely on container man-
agement of transactions and for the most part ignore them.
3.3.1
What is a transaction?
You may want to understand a bit more about what's going on with
JTA
transactions and
enterprise
OSG
i. Particularly if you're writing an application where failures and data
integrity matter, it's worth digging deeper into the world of enterprise transactions.
A transaction is a set of distinct operations that must behave like one atomic oper-
ation. If disaster strikes and one part of the group fails, the whole lot must be reversed.
LOCAL TRANSACTIONS
The simplest transactions are those that take place entirely on one resource. For exam-
ple, a database may update several rows under a single transaction to ensure the state
of the data remains consistent. In these cases there's no doubt about whether parts of
the transaction have succeeded or failed. Local transactions are sufficiently straightfor-
ward that they don't really count as part of the enterprise programming model.
DISTRIBUTED TRANSACTIONS
In the distributed case, asynchronous and unreliable communication means that
establishing whether any part of a transaction has been successful is rather more
tricky. Has a remote database not reported success because it's crashed, or because of
unusually heavy network traffic? When the transaction manager makes the decision to
commit or roll back, it's also difficult to be sure all the participants in the transaction
have followed along. Did that server fail before or after it applied the commit request?
Despite their difficulty, transactions are arguably even more essential in the distrib-
uted case. Transactions will almost certainly take longer, so the chances of multiple
users trying to access the same data at the same time are higher. What happens if an
online shopper buys a
DVD
and then cleans out their account by buying a car before
the
DVD
payment has been processed?
