openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Carter-Brown <paul.carter-br...@smilecoms.com>
Subject Inconsistent Autocommit Handling
Date Mon, 27 Oct 2008 11:45:30 GMT

Hi

In debugging a transaction related issue, I discovered the following
scenarios and just wanted to verify that these are indeed bugs:

Scenario 1
-----------------------

My setup is as follows:
Glassfish v2 with MySQL connection pool called jdbc/SmileDB with
property RelaxAutoCommit=true
OpenJPA 1.0.2

EJB with persistence.xml as follows:
<persistence version="1.0"
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">
  <persistence-unit name="AMPU" transaction-type="JTA">

<provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
    <jta-data-source>jdbc/SmileDB</jta-data-source>
    <properties>
      <property name="openjpa.Log" value="DefaultLevel=INFO,
Runtime=ERROR, Tool=ERROR, SQL=ERROR, DataCache=ERROR"/>
      <property name="openjpa.DataCache" value="false"/>
      <property name="openjpa.RemoteCommitProvider" value="sjvm"/>
    </properties>
  </persistence-unit>
</persistence>


EJB code creates entity manager as follows:
@PersistenceContext(unitName = "AMPU")
private EntityManager em;

EJB Method has following code snippet:

OpenJPAEntityManager oem = OpenJPAPersistence.cast(em);
conn = (Connection) oem.getConnection();
System.out.println("Autocommit: " + conn.getAutoCommit());

The result written out to the log is:
Autocommit: true

I would expect autocommit would be false as the connection pool has
RelaxAutoCommit=true. I have verified that the connection actually does
not autocommit: if I use it and update a table, and then throw a NPE,
the container rolls back the JTA transaction and the update is not in
the database. There thus seems to be a bug somewhere in the reporting of
the connections getAutoCommit property.


Scenario 2
-----------------------

My setup is as follows:
Glassfish v2 with MySQL connection pool called jdbc/SmileDB with
property RelaxAutoCommit=true
OpenJPA 1.0.2

EJB with persistence.xml as follows:
<persistence version="1.0"
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">
  <persistence-unit name="BSPU" transaction-type="RESOURCE_LOCAL">

<provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
    <jta-data-source>jdbc/SmileDB</jta-data-source>
    <class>com.smilecoms.bs.BatchSchedule</class>
    <exclude-unlisted-classes>true</exclude-unlisted-classes>
    <properties>
      <property name="openjpa.Log" value="DefaultLevel=INFO,
Runtime=ERROR, Tool=ERROR, SQL=ERROR, DataCache=ERROR"/>
      <property name="openjpa.DataCache" value="false"/>
      <property name="openjpa.RemoteCommitProvider" value="sjvm"/>
    </properties>
  </persistence-unit>
</persistence>

EJB code creates entity manager as follows:
EntityManagerFactory emf =
Persistence.createEntityManagerFactory("BSPU");     
EntityManager em = emf.createEntityManager();    

EJB Method has following code snippet:

OpenJPAEntityManager oem = OpenJPAPersistence.cast(em);
conn = (Connection) oem.getConnection();
System.out.println("Autocommit: " + conn.getAutoCommit());

The result written out to the log is:
Autocommit: true

I would expect autocommit would be false as the connection pool has
RelaxAutoCommit=true. I have verified that the connection does
autocommit: if I use it and update a table, and then throw a NPE, the
update is in the database. I would expect that the connection has
autocommit=false. If i specifically call conn.setAutoCommit(true) then
it does not commit until I specifically get the transaction and commit
it.

Is my understanding of OpenJPA correct and if so, should I log these
scenarios as a bug?

Thanks
Paul



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message