Re: [Springframework-developer] Reworked transaction infrastructure

[Colin S. <col...@ex...>]

Juergen,

I was looking a bit through the new code (although not enough), and was 
wondering a bit about the transaction synchronization. The bug in 
DataSourceTransactionManager/DataSourceUtils not allowing even one TM to 
have synchronization on if there is more than one TM is of course no 
longer there, and if there are multiple TMs and all except one have 
synchronization turned off, all will be ok.

However,  I am not 100% clear on what happens if more than one has it 
turned on (which will be the default when people use multiple TMs and 
don't play with the flags). I am not talking about the 
RequiresNew/Suspend situation, when it gets taken care of, but rather 
with a simple PROPOGATION_REQUIRED. As I read the new code there will 
not really be any ill effects, but rather the first TM to be involved 
will handle all synchronization, e.g.
    private TransactionStatus newTransactionStatus(Object transaction, 
boolean newTransaction,
                                                   boolean 
newSynchronization, boolean debug,
                                                   Object 
suspendedResources) {
        boolean actualNewSynchronization = newSynchronization &&
                
!TransactionSynchronizationManager.isSynchronizationActive();
        if (actualNewSynchronization) {
            TransactionSynchronizationManager.initSynchronization();
        }
        return new DefaultTransactionStatus(transaction, newTransaction, 
actualNewSynchronization,
                                            debug, suspendedResources);
    }

Is this a correct assessment?

Regards,
Colin


jürgen höller [werk3AT] wrote:

>Everybody,
> 
>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. 
> 
>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).
> 
>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.
> 
>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.
> 
>If you get the chance, please check this out promptly, as we intend to release 1.0 RC1 this weekend!
> 
>Juergen
> 
>