org.springframework.orm.jdo.JdoDialect |
Known Indirect Subclasses |
SPI strategy that allows for customizing integration with a specific JDO provider, in particular regarding transaction management and exception translation. To be implemented for specific JDO providers such as JPOX, Kodo, Lido, Versant Open Access.
JDO 2.0 defines standard ways for most of the functionality covered here.
Hence, Spring's DefaultJdoDialect
uses the corresponding JDO 2.0 methods
by default, to be overridden in a vendor-specific fashion if necessary.
Vendor-specific subclasses of DefaultJdoDialect
are still required for special
transaction semantics and more sophisticated exception translation (if needed).
In general, it is recommended to derive from DefaultJdoDialect
instead
of implementing this interface directly. This allows for inheriting common
behavior (present and future) from DefaultJdoDialect
, only overriding
specific hooks to plug in concrete vendor-specific behavior.
Public Methods | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Apply the given timeout to the given JDO query object.
| |||||||||||
Begin the given JDO transaction, applying the semantics specified by the
given Spring transaction definition (in particular, an isolation level
and a timeout).
| |||||||||||
Clean up the transaction via the given transaction data.
| |||||||||||
Retrieve the JDBC Connection that the given JDO PersistenceManager uses underneath,
if accessing a relational database.
| |||||||||||
Release the given JDBC Connection, which has originally been retrieved
via
getJdbcConnection . | |||||||||||
Translate the given JDOException to a corresponding exception from Spring's
generic DataAccessException hierarchy.
|
Apply the given timeout to the given JDO query object.
Invoked with the remaining time of a specified transaction timeout, if any.
query | the JDO query object to apply the timeout to |
---|---|
timeout | the timeout value (seconds) to apply |
if thrown by JDO methods | |
JDOException |
Begin the given JDO transaction, applying the semantics specified by the given Spring transaction definition (in particular, an isolation level and a timeout). Invoked by JdoTransactionManager on transaction begin.
An implementation can configure the JDO Transaction object and then
invoke begin
, or invoke a special begin method that takes,
for example, an isolation level.
An implementation can also apply read-only flag and isolation level to the
underlying JDBC Connection before beginning the transaction. In that case,
a transaction data object can be returned that holds the previous isolation
level (and possibly other data), to be reset in cleanupTransaction
.
Implementations can also use the Spring transaction name, as exposed by the passed-in TransactionDefinition, to optimize for specific data access use cases (effectively using the current transaction name as use case identifier).
transaction | the JDO transaction to begin |
---|---|
definition | the Spring transaction definition that defines semantics |
if thrown by JDO methods | |
SQLException | if thrown by JDBC methods |
TransactionException | in case of invalid arguments |
JDOException |
cleanupTransaction(Object)
prepareConnectionForTransaction(Connection, TransactionDefinition)
Clean up the transaction via the given transaction data. Invoked by JdoTransactionManager on transaction cleanup.
An implementation can, for example, reset read-only flag and isolation level of the underlying JDBC Connection. Furthermore, an exposed data access use case can be reset here.
transactionData | arbitrary object that holds transaction data, if any (as returned by beginTransaction) |
---|
Retrieve the JDBC Connection that the given JDO PersistenceManager uses underneath,
if accessing a relational database. This method will just get invoked if actually
needing access to the underlying JDBC Connection, usually within an active JDO
transaction (for example, by JdoTransactionManager). The returned handle will
be passed into the releaseJdbcConnection
method when not needed anymore.
Implementations are encouraged to return an unwrapped Connection object, i.e. the Connection as they got it from the connection pool. This makes it easier for application code to get at the underlying native JDBC Connection, like an OracleConnection, which is sometimes necessary for LOB handling etc. We assume that calling code knows how to properly handle the returned Connection object.
In a simple case where the returned Connection will be auto-closed with the
PersistenceManager or can be released via the Connection object itself, an
implementation can return a SimpleConnectionHandle that just contains the
Connection. If some other object is needed in releaseJdbcConnection
,
an implementation should use a special handle that references that other object.
pm | the current JDO PersistenceManager |
---|---|
readOnly | whether the Connection is only needed for read-only purposes |
releaseJdbcConnection
, or null
if no JDBC Connection can be retrievedif thrown by JDO methods | |
SQLException | if thrown by JDBC methods |
JDOException |
Release the given JDBC Connection, which has originally been retrieved
via getJdbcConnection
. This should be invoked in any case,
to allow for proper release of the retrieved Connection handle.
An implementation might simply do nothing, if the Connection returned
by getJdbcConnection
will be implicitly closed when the JDO
transaction completes or when the PersistenceManager is closed.
conHandle | the JDBC Connection handle to release |
---|---|
pm | the current JDO PersistenceManager |
if thrown by JDO methods | |
SQLException | if thrown by JDBC methods |
JDOException |
Translate the given JDOException to a corresponding exception from Spring's generic DataAccessException hierarchy. An implementation should apply PersistenceManagerFactoryUtils' standard exception translation if can't do anything more specific.
Of particular importance is the correct translation to DataIntegrityViolationException, for example on constraint violation. Unfortunately, standard JDO does not allow for portable detection of this.
Can use a SQLExceptionTranslator for translating underlying SQLExceptions in a database-specific fashion.
ex | the JDOException thrown |
---|
null
)