Java Reference
In-Depth Information
class="org.apache.commons.dbcp.BasicDataSource">
<property name="driverClassName">
<value>oracle.jdbc.driver.OracleDriver</value>
</property>
<property name="defaultTransactionIsolation">
<value>SERIALIZABLE</value>
</property>
…
This bean's definition uses the
defaultTransactionIsolation
property to specify
that all connections created by this
DataSource
should use the serializable isolation
level. Other
DataSource
implementations typically have an equivalent mechanism.
A
DAO
that uses serializable transactions, optimistic locking, and pessimistic
locking will naturally encounter concurrency failures, which can occur when two
transactions try to access the same data simultaneously. It must report the failure
by throwing an exception. Let's see how to do this.
12.2.5
Signaling concurrent update failures
A concurrency failure occurs when either the
DAO
or the database determines
that two transactions cannot be executed concurrently. If the application is using
optimistic locking, the
DAO
will be unable to update a row because it has been
updated or deleted by another transaction. Or, if the application is using serializ-
able transactions or pessimistic locking, the database will detect a deadlock or
some other condition and
JDBC
throws a
SQLException
. A
DAO
must report a con-
currency failure by throwing an exception so that a higher level application com-
ponent can recover from the error by rolling back or retrying the transaction or
by displaying an error message to the user.
A
DAO
could, for example, allow the
JDBC
SQLException
to propagate to its
caller, but there are two reasons why this is not a good idea. The first problem with
throwing a
SQLException
is that it is
JDBC
-specific. An application might also be
using a persistence framework such as
JDO
, which throws different exceptions.
Ideally, the higher level components of the application should not know how the
lower levels access the database. Another problem with
SQLException
is that it is a
checked exception, which would require the callers of the
DAO
to either catch it
or declare it as being thrown, which just clutters up the code. It is much better to
use unchecked exceptions to report a concurrency failure.
Spring provides a very elegant solution to this problem. It has an unchecked
exception class hierarchy for data access errors that enables an application to treat
data access errors uniformly regardless of whether it is using
JDBC
, Hibernate, or
JDO
. It also has an extensible mechanism for automatically translating exceptions
Search WWH ::
Custom Search