[Springframework-developer] Refined JDO support

[<jue...@we...>]

Hi everybody,

I've significantly refined Spring's JDO support, to get it closer to the =
level of our Hibernate support:

* Standard JDOException -> DataAccessException conversion in =
PersistenceManagerFactoryUtils is more sophisticated now, properly =
detecting JDOObjectNotFoundException, JDOOptimisticVerificationException =
and JDODataStoreException. For more sophisticated, =
implementation-specific exception translation (for example, detecing =
data integrity violation), there's still the need to implement =
JdoDialect's "translateException" method.

* JdoDialect has a "beginTransaction" method now, passing in a Spring =
TransactionDefinition. Implementations can apply the isolation level =
and/or transaction timeout before they call javax.jdo.Transaction's =
"begin". Spring's JdoTransactionManager delegates to this method; =
DefaultJdoDialect does nothing special here, but custom JdoDialect =
implementations can override this. (Note that both =
HibernateTransactionManager and DataSourceTransactionManager support =
isolation levels and timeouts.)

* JdoDialect has a "releaseJdbcConnection" method now, for JDO =
implementations that expect the JDBC Connection handle that they =
returned on "getJdbcConnection" to be explictly released. (If explicit =
closing is not necessary, this method can be empty.) Spring's =
JdoTransactionManager properly invokes "releaseJdbcConnection" on =
transaction cleanup. Note that "getJdbcConnection" returns a =
ConnectionHandle, to be passed into "releaseJdbcConnection", which =
allows for a wider range of release strategies.

* JdoTemplate features a number of convenience methods now, for typical =
data access operations (load, save, delete, find). Those methods are =
defined in the new JdoOperations interface; this is analagous to =
HibernateTemplate and HibernateOperations. The names of the methods =
follow JDO naming conventions, to look natural to people that are used =
to the PersistenceManager API (and to imply the same semantics). For =
more sophisticated querying needs, you still need to implement a =
JdoCallback and work with the JDO Query API.

* The jdo.support package provides =
OpenPersistenceManagerInViewInterceptor (for Spring's web MVC framework) =
and OpenPersistenceManagerInViewFilter (Servlet 2.3 Filter) =
implementations now, for keeping a PersistenceManager open during the =
entire request processing. Spring-managed transactions will simply work =
on that thread-bound PersistenceManager. This is particularly useful for =
JDO, as the PersistenceManager will always be in a consistent state, =
even if exceptions got thrown (in contrast to Hibernate).

All of this should work with any (relational) JDO 1.0 implementation. =
Please review those refinements and tell me about any gaps or =
inconsistencies!

-----

Note that a vendor-specific JdoDialect implementation is just necessary =
for specific features, namely special transaction semantics, JDBC =
Connection exposure by JdoTransactionManager, eager flushing by =
JdoTemplate. JdoTemplate's convenience operations and =
OpenPersistenceManagerInViewInterceptor/Filter will work nicely with the =
default JdoDialect.

I've prototypically implemented the JdoDialect interface for JPOX =
(http://www.jpox.org), which supports per-transaction isolation levels, =
exposing transaction-scoped JDBC Connections, and eager flushing. This =
should be straightforward to implement for other JDO vendors. Such =
implementations will usually derive from Spring's DefaultJdoDialect and =
just override specific methods.

JDO 2.0 standardizes some aspects of JdoDialect, namely JDBC Connection =
access and eager flushing. I plan to adapt DefaultJdoDialect =
accordingly, once a JDO 2.0 API jar is available. Note that there's =
still value in providing a special DefaultJdoDialect subclass for each =
JDO 2 product, for special transaction semantics and more sophisticated =
exception translation.

-----

As these changes are straightforward enhancements, they will be part of =
Spring 1.0.3 if there's no major obstacle.

Unfortunately, the JdoDialect SPI has changed in an incompatible =
fashion, but I doubt that this will cause any hassle, as it's more or =
less unadvertised at this point of time. And if someone already uses our =
JDO support with a custom JdoDialect, it is straightforward to adapt the =
JdoDialect implementation to the new SPI.

Juergen