Database transactions and concurrency - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 470

A DAO that implements optimistic locking must explicitly throw an Optimistic-
LockingFailureException when it fails to update a row. However, Spring's JDBC
and i BATIS classes automatically map SQLException s to Spring data access excep-
tions. This means, for example, that if you use a SqlMapClientTemplate to execute
a SQL statement that results in an error, Spring will map the SQLException to the
appropriate subclass of DataAccessException .
One minor issue with Spring's SQLException mapping mechanism is that it
does not recognize all error codes. For example, in the case of Oracle, Spring will
map an ORA-00054 error code, which indicates that a row cannot be locked imme-
diately, to a CannotAcquireLockException , but it does not recognize ORA-00060
and ORA-08177 error codes, which indicate other concurrency failures, and maps
them to an UncategorizedSQLException . This is a shame because, as I mentioned
earlier, an ORA-00060 error code indicates a deadlock and an ORA-08177 error
indicates a serialization failure. In order to map those error codes to the appropri-
ate subclass of ConcurrencyFailureException , we must use extend the Spring
SQLException mapping mechanism.

Extending Spring's SQLException mapping mechanism
Data access template classes such as SqlMapClientTemplate use a SQLException-
Translator to map SQLException s to Spring data access exceptions. As figure 12.5
shows,this interface defines a translate() method that takes a SQLException as a

OrderDAO

<< interface>>
SQLExceptionTranslator

SqlMapClient
Template

DataAccessException translate(... ,SQLException)

SQLErrorCode
SQLException
Translator

MyOracleSQLExceptionTranslator

DataAccessException customTranslate(... ,SQLException)

Figure 12.5 Extending the Spring SQLException mapping mechanism