Details

Description

Someone just had a lot of weird transaction errors that turned out to be because they had configured a persistence.xml with JTA transaction support and only a non-jta-datasource that was actually transactional. When both the tm and openjpa tried to control the tx confusion enused.

We can detect this situation on deployment and either reject it or at least loudly warn about it.

in the persistence.xml you can specify <jta-datasource> and <non-jta-datasource>. In this case only the <non-jta-datasource> was specified. However, the datasource configured there should have had

<no-transaction/> in its plan but had either

<local-transaction/>
or
<xa-transaction/>

Openjpa uses the non-jta-datasource for things like creating tables, getting "sequence" values from tables outside a jta transaction, and similar things. It uses the connection.commit style of local transaction management which causes exceptions if the connection is already enrolled in an XA transaction since it's from a transactional datasource.

David Jencks
added a comment - 28/May/12 04:11 Thanks for looking into this.
in the persistence.xml you can specify <jta-datasource> and <non-jta-datasource>. In this case only the <non-jta-datasource> was specified. However, the datasource configured there should have had
<no-transaction/> in its plan but had either
<local-transaction/>
or
<xa-transaction/>
Openjpa uses the non-jta-datasource for things like creating tables, getting "sequence" values from tables outside a jta transaction, and similar things. It uses the connection.commit style of local transaction management which causes exceptions if the connection is already enrolled in an XA transaction since it's from a transactional datasource.
If this is not enough information let me know.