versions:
- spring 2.0RC1
- hibernate/annotations/entitymanager 3.2.0CR1
persistence.xml:
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
version="1.0">
<persistence-unit name="OpenTrader" transaction-type="JTA"/>
</persistence>
Spring LCEMFB config:
<bean id="persistence.dataSource" class="org.apache.commons.dbcp.BasicDataSource" >
...
</bean>
<bean id="persistence.loadTimeWeaver" class="org.springframework.instrument.classloading.Instru mentationLoadTimeWeaver"/>
<!-- For reasons not yet known, hibernate needs this in order to find the JTA TransactionManager -->
<bean id="persistence.transactionManagerLookup" class="org.opentrader.infra.hibernate.TransactionManagerH olderLookup">
<property name="transactionManager" ref="txn.userTransactionManager"/>
</bean>
<!-- NOTE We depends-on 'persistence.transactionManagerLookup' to ensure that it the concrete bean. Otherwise hibernate gets very upset. -->
<bean id="persistence.entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityMa nagerFactoryBean"
depends-on="persistence.transactionManagerLookup">
<property name="allowRedeploymentWithSameName" value="true"/>
<property name="dataSource" ref="persistence.dataSource"/>
<property name="loadTimeWeaver" ref="persistence.loadTimeWeaver"/>
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVen dorAdapter">
<property name="database" value="${persistence.jpa.database}"/>
<property name="showSql" value="${hibernate.show_sql}"/>
</bean>
</property>
<property name="jpaPropertyMap">
<props>
<prop key="hibernate.ejb.use_class_enhancer">false</prop>
<prop key="hibernate.transaction.manager_lookup_class">org.opentrader.infra.hibernate.TransactionManagerH olderLookup</prop>
<prop key="hibernate.current_session_context_class">jta</prop>
</props>
</property>
</bean>
The first concern which may or may not give some clues, is that hibernate does not find the transaction manager unless I provide it with a "hibernate.transaction.manager_lookup_class":
public class TransactionManagerHolderLookup implements TransactionManagerLookup {
private static TransactionManager transactionManager;
public void setTransactionManager(TransactionManager transactionManager) {
Assert.notNull(transactionManager, "transactionManager must not be null");
TransactionManagerHolderLookup.transactionManager = transactionManager;
}
public TransactionManager getTransactionManager(Properties props) throws HibernateException {
return transactionManager;
}
public String getUserTransactionName() {
return null;
}
}
I have no idea why this mechanism is required, but hibernate fails to initialize without it.
I'm using the Geronimo transaction manager packaged with Jencks. I have had no problems with transactions when using straight hibernate (ie, pre JPA). Here is the tail end of the config for transaction related beans:
...
<bean id="txn.userTransactionManager"
class="org.jencks.factory.GeronimoTransactionManagerFacto ryBean">
<property name="transactionContextManager" ref="tnx.jencks.transactionContextManager"/>
</bean>
<bean id="txn.platformTransactionManager" lazy-init="true"
class="org.springframework.transaction.jta.JtaTransaction Manager">
<property name="userTransaction" ref="txn.userTransactionManager" />
</bean>
<bean
class="org.springframework.transaction.aspectj.Annotation TransactionAspect"
factory-method="aspectOf">
<property name="transactionManager" ref="txn.platformTransactionManager" />
</bean>
Ok, now for the actual code. The test that is failing is related to a class which provides a Hibernate impl of ACEGI UserDetails -- its simple so I'll just show snippets of it instead of creating a dummy example (later, if I'm not doing something stupid, I'll create a isolated repeatable test that I can submit to jira).
@Transactional
public class UserService implements UserDetailsService {
@PersistenceContext
private EntityManager em;
...
public User findUserByUsername(String username) throws UsernameNotFoundException {
try {
User user = (User)em.createNamedQuery("opentrader.security.findUserByUsername")
.setParameter("username", username)
.getSingleResult();
return user;
} catch (NoResultException e) {
throw new UsernameNotFoundException("User not found: username=" + username);
}
}
public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
return findUserByUsername(username);
}
}
The test is testing the failure of the method "loadUserByUsername" which simply delegates to "findUserByUsername":
public void testLoadUserByUsername_NotExists() {
try {
service.loadUserByUsername(usernames.generate());
fail("expected UsernameNotFoundException");
} catch (UsernameNotFoundException e) {
// expected
}
}
Here is the sequence:
1. the test invokes service.loadUserByUsername
2. via the txn aspect, TransactionAspectSupport.createTransactionIfNecess ary is invoked and a new transaction is created
3. service.loadUserByUsername invokes this.findUserByUsername
4. again via the txn aspect, TransactionAspectSupport.createTransactionIfNecess ary is invoked yet this time spring sees that the a transaction is already in progress and the transactionStatus has newSynchronization=false and newTransaction=false
5. findUserByUsername fails and throws an exception (as per the test setup)
6. via the txn aspect, TransactionAspectSupport.doCloseTransactionAfterTh rowing gets invoked, which leads to AbstractPlatformTransactionManager.triggerBeforeCo mpletion. This method sees that the txn status is not a new-sync, and shorts out.
7. the expection propagates to loadUserByUsername, which triggers the txn advice and leads back to AbstractPlatformTransactionManager.triggerBeforeCo mpletion. This time the status /is/ for a new-sync, which happens to be EntityManagerFactoryUtils$EntityManagerSynchroniza tion.
8. EntityManagerFactoryUtils$EntityManagerSynchroniza tion.beforeCompletion is invoked, which first calls TransactionSynchronizationManager.unbindResource(t his.entityManagerFactory) and then calls this.entityManagerHolder.getEntityManager().close( )
Ok, its this last invocation, this.entityManagerHolder.getEntityManager().close( ), where the problem lies. This method call leads to hibernate EntityManagerImpl.close()
- which invokes getSession().getTransaction().registerSynchronizat ion(...)
- which invokes CMTTransaction.registerSynchronization()
- which invokes getTransaction().registerSynchronization(sync)
This last goes into Geronimo, which throws a RollbackException with the message "Transaction is marked for rollback". All this perculates back up to AbstractPlatformTransactionManager which catchs the exception, eats it and logs an error.
So, not being a JTA guru, all I can surmize is that either some protocol is being violated by spring/hibernate/geronimo, or some part of the code is doing something in the wrong order.
This is all very complex. And when I switch back to RESOURCE_LOCAL, my database commits never happen. Buts that another story.