Transaction aware objects in stateless EJB

0
votes

I'm little confused how transactions work in EJBs. I've always thought that all transaction aware objects in container managed EJBs are all committed or rollbacked when a method with TransactionAttribute=REQUIRED_NEW is finished but unfortunately it's not in my case. I don't have my code in front of me so I can't include whole example but what I ask for is just the confirmation of the idea of how it should work.
Only key points of my code just from the top of my head are presented: 

EntityManager em; //injected
[...]
public void someEJBMethod() {
  [...]
  em.persist(someObject);
  [...]
  Session session = JpaHelper.getEntityManager(em).getActiveSession();
  [...]
  session.executeQuery(query, args);
  [...]
  if (someCondition) {
    throw new EJBException();
  }  
  [...]
}

And my problem is that when EJBException is thrown database changes caused by em.persist are rollbacked but changes caused by session.executeQuery are committed. Is it expected behaviour?
I'm using Glassfish 3.1.2, EclipseLink 2.3.2 with Oracle database

Update (test case added)
I've created working test case to show the problem

First database objects: 

create table txtest
(id number not null primary key,
 name varchar2(50) not null);

create or replace function txtest_create(p_id number, p_name varchar2) return number is
begin
  insert into txtest
  (id, name)
  values
  (p_id, p_name);

  return p_id;
end;

Definition of a database connection (from domain.xml) 

<jdbc-connection-pool driver-classname="" datasource-classname="oracle.jdbc.pool.OracleConnectionPoolDataSource" res-type="javax.sql.ConnectionPoolDataSource" description="" name="TxTest">
  <property name="User" value="rx"></property>
  <property name="Password" value="rx"></property>
  <property name="URL" value="jdbc:oracle:thin:@test:1529:test"></property>
</jdbc-connection-pool>
<jdbc-resource pool-name="TxTest" description="" jndi-name="jdbc/TxTest"></jdbc-resource>

persistence.xml 

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.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_2_0.xsd">
    <persistence-unit name="txTest">
        <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
        <jta-data-source>jdbc/TxTest</jta-data-source>
        <class>txtest.TxTest</class>
    </persistence-unit>
</persistence>

session bean: 

@Stateless
public class TxTestBean implements TxTestBeanRemote, TxTestBeanLocal {
    private static Logger log = Logger.getLogger(TxTestBean.class.getName());

    @PersistenceContext(unitName="txTest")
    EntityManager em;

    @SuppressWarnings({ "unchecked", "rawtypes" })
    @Override
    public void txTest(boolean throwException) {
        TxTest t = new TxTest();
        t.setId(1L);
        t.setName("em.persist");
        em.persist(t);

        Session session = JpaHelper.getEntityManager(em).getActiveSession();
        log.info("session : " + String.valueOf(System.identityHashCode(session)));
        PLSQLStoredFunctionCall call = new PLSQLStoredFunctionCall();
        call.setProcedureName("txtest_create");
        call.addNamedArgument("p_id", JDBCTypes.NUMERIC_TYPE);
        call.addNamedArgument("p_name", JDBCTypes.VARCHAR_TYPE, 50);
        call.setResult(JDBCTypes.NUMERIC_TYPE);

        ValueReadQuery query = new ValueReadQuery();
        query.setCall(call);
        query.addArgument("p_id");
        query.addArgument("p_name");

        t = new TxTest();
        t.setId(2L);
        t.setName("session.executeQuery");

        List args = new ArrayList();
        args.add(t.getId());
        args.add(t.getName());

        Long result = ((Number)session.executeQuery(query, args)).longValue();

        //added to see the state of txtest table in the database before exception is thrown
        try {
            Thread.sleep(20000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        log.info("result=" + result.toString());

        if (throwException) {
            throw new EJBException("Test error #1");
        }
    }
}

entries from server.log when txTest(true) is invoked: 

[#|2012-05-21T12:04:15.361+0200|FINER|glassfish3.1.2|org.eclipse.persistence.session.file://txTest/_txTest.connection|_ThreadID=167;_ThreadName=Thread-2;ClassName=null;MethodName=null;|client acquired: 21069550|#]
[#|2012-05-21T12:04:15.362+0200|FINER|glassfish3.1.2|org.eclipse.persistence.session.file://txTest/_txTest.transaction|_ThreadID=167;_ThreadName=Thread-2;ClassName=null;MethodName=null;|TX binding to tx mgr, status=STATUS_ACTIVE|#]
[#|2012-05-21T12:04:15.362+0200|FINER|glassfish3.1.2|org.eclipse.persistence.session.file://txTest/_txTest.transaction|_ThreadID=167;_ThreadName=Thread-2;ClassName=null;MethodName=null;|acquire unit of work: 16022663|#]
[#|2012-05-21T12:04:15.362+0200|FINEST|glassfish3.1.2|org.eclipse.persistence.session.file://txTest/_txTest.transaction|_ThreadID=167;_ThreadName=Thread-2;ClassName=null;MethodName=null;|persist() operation called on: txtest.TxTest@11b9605.|#]
[#|2012-05-21T12:04:15.363+0200|INFO|glassfish3.1.2|txtest.TxTestBean|_ThreadID=167;_ThreadName=Thread-2;|session : 16022663|#]
[#|2012-05-21T12:04:15.364+0200|FINEST|glassfish3.1.2|org.eclipse.persistence.session.file://txTest/_txTest.query|_ThreadID=167;_ThreadName=Thread-2;ClassName=null;MethodName=null;|Execute query ValueReadQuery()|#]
[#|2012-05-21T12:04:15.364+0200|FINEST|glassfish3.1.2|org.eclipse.persistence.session.file://txTest/_txTest.connection|_ThreadID=167;_ThreadName=Thread-2;ClassName=null;MethodName=null;|Connection acquired from connection pool [read].|#]
[#|2012-05-21T12:04:15.364+0200|FINEST|glassfish3.1.2|org.eclipse.persistence.session.file://txTest/_txTest.connection|_ThreadID=167;_ThreadName=Thread-2;ClassName=null;MethodName=null;|reconnecting to external connection pool|#]
[#|2012-05-21T12:04:15.365+0200|FINE|glassfish3.1.2|org.eclipse.persistence.session.file://txTest/_txTest.sql|_ThreadID=167;_ThreadName=Thread-2;ClassName=null;MethodName=null;|
DECLARE
  p_id_TARGET NUMERIC := :1;
  p_name_TARGET VARCHAR(50) := :2;
  RESULT_TARGET NUMERIC;
BEGIN
  RESULT_TARGET := txtest_create(p_id=>p_id_TARGET, p_name=>p_name_TARGET);
  :3 := RESULT_TARGET;
END;
  bind => [:1 => 2, :2 => session.executeQuery, RESULT => :3]|#]
[#|2012-05-21T12:04:15.370+0200|FINEST|glassfish3.1.2|org.eclipse.persistence.session.file://txTest/_txTest.connection|_ThreadID=167;_ThreadName=Thread-2;ClassName=null;MethodName=null;|Connection released to connection pool [read].|#]
[#|2012-05-21T12:04:35.372+0200|INFO|glassfish3.1.2|txtest.TxTestBean|_ThreadID=167;_ThreadName=Thread-2;|result=2|#]
[#|2012-05-21T12:04:35.372+0200|FINER|glassfish3.1.2|org.eclipse.persistence.session.file://txTest/_txTest.transaction|_ThreadID=167;_ThreadName=Thread-2;ClassName=null;MethodName=null;|TX afterCompletion callback, status=ROLLEDBACK|#]
[#|2012-05-21T12:04:35.372+0200|FINER|glassfish3.1.2|org.eclipse.persistence.session.file://txTest/_txTest.transaction|_ThreadID=167;_ThreadName=Thread-2;ClassName=null;MethodName=null;|release unit of work|#]
[#|2012-05-21T12:04:35.372+0200|FINER|glassfish3.1.2|org.eclipse.persistence.session.file://txTest/_txTest.connection|_ThreadID=167;_ThreadName=Thread-2;ClassName=null;MethodName=null;|client released|#]
[#|2012-05-21T12:04:35.373+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=167;_ThreadName=Thread-2;|EJB5184:A system exception occurred during an invocation on EJB TxTestBean, method: public void txtest.TxTestBean.txTest(boolean)|#]
[#|2012-05-21T12:04:35.373+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=167;_ThreadName=Thread-2;|javax.ejb.EJBException: Test error #1

What surprised me the most is that when I checked txtest table during this 20 sec. sleep the record (2,"session.executeQuery") was already there.
It seems like session.executeQuery somehow commits its work (but not the whole transaction).

Can someone explain this behaviour?

2
jpatransactionsejbeclipselink

2 Answers

4
votes

I'm not sure what JpaHelper.getEntityManager(em).getActiveSession(); is supposed to do exactly, but it seems likely this doesn't return a container managed entity manager. Depending on how it's exactly implemented, this may not participate in the ongoing (JTA) transaction.

Normally though, transactional resources all automatically participate in the ongoing JTA transaction. In broad lines they do this by checking if there's such on ongoing transaction, and if there indeed is, they register themselves with this transaction.

In EJB, REQUIRES_NEW is not the only mode that can start a transaction 'REQUIRES' (the default) also does this incase the client didn't start a transaction.

1
votes

I've got it solved!!!

It turned out that EclipseLink uses read connection pools for processing read queries (and obviously that kind of pools uses autocommit or even don't use transactions at all) and default connection pools for data modification queries. So what I had to do was changing: 

ValueReadQuery query = new ValueReadQuery();

into 

DataModifyQuery query = new DataModifyQuery();

and it works like a charm.

Update
DataModifyQuery doesn't allow to get the result of the function. It returns the number of modified rows. So I got back to ValueReadQuery but used configuration parameter in persistance.xml 

<property name="eclipselink.jdbc.exclusive-connection.mode" value="Always"/>

This parameter tells EclipseLink to use default connection pool for both reads and writes.