[Springframework-developer] Reworked transaction infrastructure

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

Everybody,
=20
I've significantly reworked our transaction infrastructure last week, to =
effectively provide the same support for transaction suspension as EJB =
CMT does.  Accordingly, I've introduced propagation behaviors =
"REQUIRES_NEW", "NOT_SUPPORTED", and "NEVER" for all our =
PlatformTransactionManagers. I've committed this yesterday evening, now =
that CVS seems to work again.

JtaTransactionManager needs to access the =
javax.transaction.TransactionManager for transaction suspension; =
unfortunately, the TransactionManager location is not defined by J2EE =
(O/R mappers have a similar problem for cache callbacks in a JTA =
environment). Thus, I've introduced a JtaDialect interface (analogous to =
our JdoDialect), containing "getInternalTransactionManager" and =
"applyIsolationLevel" methods (the latter factored out from =
JtaTransactionManager's template method into this strategy).

The default dialect implementations is JndiLookupJtaDialect, with a =
configurable "templateManagerName" JNDI location (not doing anything =
about the isolation level); its Javadoc states a couple of well-known =
JTA TransactionManager locations in popular application servers. =
Additionally, I've added JotmJtaDialect and WebSphereJtaDialect, which =
both require specific static accessor methods to obtain the JTA =
TransactionManager. I've simply taken the corresponding code from =
Hibernate's TransactionManagerLookups.

There's also a new "jtaDialect" property in LocalSessionFactoryBean, =
allowing to use a Spring-configured JtaDialect for Hibernate's =
TransactionManagerLookup. This avoids double configuration of the =
server-specific lookup strategy. As when providing a DataSource, the =
corresponding Hibernate property will be set implictly when a JtaDialect =
is provided.=20
=20
I've tested transaction suspension with HibernateTransactionManager and =
DataSourceTransactionManager in Tomcat, Resin, and JBoss; with =
JtaTransactionManager and a corresponding JndiLookupJtaDialect, in Resin =
and JBoss. Works nicely in all cases: I'd be happy if someone else tried =
WebLogic, WebSphere, JOTM, etc (there's nothing to worry about there, =
just validating the TransactionManager lookup strategies).
=20
I've also added a ClobStringType for Hibernate, using a =
LocalSessionFactoryBean-specified LobHandler for mapping Strings to =
CLOBs. You can specify ClobStringType for such fields in your Hibernate =
mappings even if just using CLOBs in certain environments: =
DefaultLobHandler will simply delegate to =
PreparedStatement.setString/ResultSet.getString anyway. On Oracle, =
simply configure OracleLobHandler in your application context - the =
Hibernate mapping file does not have to change.
=20
ClobStringType is particularly useful if you need Strings with more than =
4000 characters in Oracle mapped to persistent objects via Hibernate. =
You need to use CLOBs for such long texts in Oracle; and due to Oracle's =
peculiar handling of LOBs, you need a special strategy like =
OracleLobHandler. On other databases like MySQL, type "longtext" is =
fine, to be used like normal String values. Our LobHandler abstraction =
allows to turn this into a configuration issue.
=20
If you get the chance, please check this out promptly, as we intend to =
release 1.0 RC1 this weekend!
=20
Juergen
=20