Re: [Springframework-developer] Refined JDO support

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

I've just refined DefaultJdoDialect to use a Spring =
SQLExceptionTranslator for its "translateException" implementation. =
That's one more step closer to the sophistication of our Hibernate =
support!

So if DefaultJdoDialect receives a JDOException that has a SQLException =
as cause, the SQLExceptionTranslator will kick in and convert it to an =
appropriate subclass of Spring's DataAccessException hierarchy, for =
example DataIntegrityViolationException.

The actual SQLExceptionTranslator implementation gets determined via the =
PersistenceManagerFactory: If the ConnectionFactory there is a JDBC =
DataSource, a SQLErrorCodeSQLExceptionTranslator will be used, using =
database-specific error code analysis. As a fallback, =
SQLStateSQLExceptionTranslator will be used.

This works nicely with JPOX, and I assume also with Kodo. The only =
requirement is that the SQLException is the immediate cause of the =
JDOException that gets thrown. I assume that this applies to most =
relational JDO implementations.

Note that this behavior is now the default, as JdoTransactionManager and =
JdoTemplate will use a properly configured DefaultJdoDialect as default! =
Just if the actual JDO implementation does not comply with these =
assumptions, a specific subclass with an overridden "translateException" =
method is necessary.

So once the JDO 2.0 API is available and DefaultJdoDialect is properly =
adapted to it (i.e. getJdbcConnection and flush delegate to the =
corresponding JDO 2.0 methods), the only remaining reason for a =
vendor-specific JdoDialect for a JDO 2.0 product will be special =
transaction semantics (isolation level, timeout).

-----

BTW, HibernateTransactionManager and HibernateAccessor use a similar =
SQLExceptionTranslator determination strategy now: If a DataSource is =
available, SQLErrorCodeSQLExceptionTranslator; else, =
SQLStateSQLExceptionTranslator. Formerly, they always used the latter if =
not explicitly overridden.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Wednesday, June 16, 2004 12:18 PM
To: spr...@li...
Subject: [Springframework-developer] Refined JDO support


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


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer