Hi everybody,
I've just finished the last bunch of data access refinements I wanted to get
into Spring 1.2 final:
* The TopLink support is able to expose a transaction-aware TopLink Session
as bean reference, to be passed to plain TopLink DAOs which use TopLink API
only (without Spring dependencies in DAO code). Such a Session exposes the
Spring-managed transactional Session on "Session.getActiveSession" and
"Session.getActiveUnitOfWork", analogous to TopLink's behavior in a JTA
environment. I've confirmed that this works on both TopLink 9.0.4 and
10.1.3.
* The Hibernate3 support exposes a SessionFactory proxy that returns the
Spring-managed transactional Session on Hibernate 3.0.1's
"SessionFactory.getCurrentSession", analogous to Hibernate's behavior in a
JTA environment. This allows plain Hibernate DAOs to receive a
SessionFactory reference and participate in Spring-managed transactions with
Hibernate API only, being able to seamlessly participate in plain JTA
transactions as well.
* Our LocalSessionFactoryBean for Hibernate3 sets Hibernate 3.0.3's
Connection release mode to "after_transaction" or "after_statement",
depending on the transaction awareness of the underlying DataSource. The
resulting behavior is much nicer than before: using a transaction-aware
DataSource for the Hibernate SessionFactory is not an issue anymore, not
even with Open Session In View, removing a configuration headache when you
need stuff like transaction timeouts for inserts/updates. Issues with
misbehaving JTA implementations can be solved with this as well.
* The JDO support includes a TransactionAwarePersistenceManagerFactoryProxy,
exposing a JDO PersistenceManagerFactory reference that returns the
Spring-managed transactional PersistenceManager on "getPersistenceManager",
and suppresses "PersistenceManager.close" accordingly. This allows plain JDO
DAOs to receive a PersistenceManagerFactory reference and participate in
Spring-managed transactions with JDO API only.
* Spring's JDO support fully covers JDO 2.0 now, both in terms of
JdoTemplate operations (getObjectById behavior, detach, reattach,
findByNamedQuery, find with single string query, etc) and in terms of the
DefaultJdoDialect implementation (flush, JDBC Connection access). I have
tested this against JPOX 1.1.0 beta 3 as well as against JPOX 1.0, for
compatibility with both JDO 2.0 and 1.0. The JDO2 API jar that we compile
against is the pre-release jar taken from JPOX.
* I've refined the semantics of the "allowCreate" flag for all of our ORM
templates: This only applies to the creation of non-transactional resources
now. If "allowCreate" is "false", on-the-fly synchronization of a resource
with the current transaction is still allowed. This is in line with the
behavior of TopLink's "getActiveSession" and Hibernate3's
"getCurrentSession", and IMO generally reasonable: eager vs lazy transaction
synchronization should be fully transparent to the user; usually, only the
creation of a non-transactional resource is (potentially) undesirable.
* I've also deprecated all our "closeXxxIfNecessary" methods in favor of new
"releaseXxx" methods. "get"/"release" pairs are much nicer than
"get"/"closeIfNecessary", in particular as the release methods do not just
perform close-if-necessary anymore: they also manage reference counters etc.
"release" is the proper term for what they do these days, IMO (and is also
the term used by TopLink, BTW).
I'm going into sample app test mode now, and intend to go forward with the
actual Spring 1.2 final release if there aren't any objections. So if you
have any feedback on those recent changes, please voice it at your earliest
convenience :-) The actual release won't happen before tonight, so there's
still half a day to go.
Juergen
|
