Java Reference
In-Depth Information
<beans>
…
<bean id="HibernateTemplate"
class="org.springframework.orm.hibernate3.HibernateTemplate">
<property name="sessionFactory">
<ref bean="mySessionFactory"/>
</property>
<property name="jdbcExceptionTranslator">
<ref bean="ExceptionTranslator"/>
</property>
</bean>
…
</beans>
ExceptionTranslator
is the Spring bean that configures the
MyOracleSQLExcep-
tionTranslator
that we saw earlier. The
HibernateTemplate
will then map
SQLEx-
ception
s using the
MyOracleSQLExceptionTranslator
. Concurrency errors that are
reported as
JDBC
exceptions will automatically be mapped to the appropriate sub-
class of
ConcurrencyFailureException
.
Signaling a concurrency failure is just the first step in the process of handling
the error. Most of the time an application should attempt to recover from the fail-
ure by retrying the transaction; in the next section we'll see how that works.
12.4 Recovering from data concurrency failures
I live a few miles from a major earthquake fault, and it's inevitable that the big one
will eventually happen. The key to getting through such a disaster is having a seis-
mically retrofitted house along with a plan and supplies. On a much smaller scale,
it's inevitable that concurrency failures will occur from time to time in an applica-
tion. The application must be prepared to handle them in a meaningful way. Ide-
ally, it should do more than simply display an error screen to the user.
As we have seen, the database access layer of a Spring application reports a
concurrency failure by throwing a subclass of
ConcurrencyFailureException
.
Because
ConcurrencyFailureException
is an unchecked exception, in most appli-
cations it will propagate to the
TransactionInterceptor
, which wraps the business
logic and makes it transactional. By default,
TransactionInterceptor
handles an
unchecked exception by first making sure that the transaction is rolled back and
then rethrowing the exception. However, because data concurrency failures are
almost always transient, most applications should retry the transaction again
instead of propagating the exception to the presentation tier.
We could place the burden of retrying transactions on the business logic's cli-
ent. It would wrap each call to the business tier in a
try/catch
block and retry the
Search WWH ::
Custom Search