Java Reference
In-Depth Information
The sequence of events is as follows:
The servlet calls the
TransactionRetryInterceptor
.
1
The
TransactionRetryInterceptor
calls the
TransactionInterceptor
.
2
The
TransactionInterceptor
begins a transaction.
3
The
TransactionInterceptor
calls the
PlaceOrderService
.
4
The
PlaceOrderService
throws an exception.
5
The
TransactionInterceptor
catches the exception and rolls back the
transaction.
6
The
TransactionRetryInterceptor
catches the exception rethrown by the
TransactionInterceptor
and calls the
TransactionInterceptor
.
7
The second time around, the call to
PlaceOrderService
via the
TransactionIn-
terceptor
succeeds.
Using this interceptor is straightforward in a
JDO
application because the
JDO
specification allows a
PersistenceManager
to be reused after an exception is
thrown. However, retrying a transaction is a lot more difficult in a Hibernate appli-
cation because the Hibernate documentation states that the application must
close the existing
Session
and open a new one if Hibernate throws an exception.
One solution to this limitation of Hibernate is to use the
OpenSessionInView-
Filter
in a mode that uses a separate
Session
for each transaction and data access
operation. This mode, which is known as the deferred close method, is enabled by
setting the
singleSession
property of the
OpenSessionInViewFilter
to
false
.
Each time a transaction is retried a new
Session
will be opened, which avoids the
problem of
Session
reuse. Any lazy loading that occurs after the transaction com-
mits will use the
Session
that was opened at the start of the transaction. The
OpenSessionInViewFilter
closes all sessions prior to returning. One drawback
with this approach is that each call to a repository outside of the transaction will
use its own
Session
, which can be inefficient. In addition to using extra database
connections, it will bypass any session-level caching and use extra database
accesses. You can also end up with objects belonging to multiple sessions, which
can sometimes be confusing.
An alternative approach is to disregard the advice in the Hibernate documen-
tation and to continue to reuse the
Session
. Spring's
HibernateTransactionMan-
ager
automatically calls
Session.clear()
when a transaction is rolled back. In the
current version of Hibernate, this method clears the session-level cache and
ensures that the
Session
is in a pristine state at the start of the next transaction.
Search WWH ::
Custom Search