javax.persistence. TransactionRequiredException

[John King]

I'm using JBoss4.2.2 with EJB3 stateless session bean and JPA/Hibernate with Oracle10g:

I can query the DB w/o any problems. When I do update, I got

"javax.persistence.TransactionRequiredException: no transaction is in progress" on the EJB client side. There is no Exception on server side.

Here is the update method in stateless session bean:

@TransactionAttribute (TransactionAttributeType.REQUIRED)
public void changeSalary(int id, long salary) throws IOException
{
Employee empEntity = this.entityManager.find(Employee.class, id);
empEntity.setSalary(salary);
this.entityManager.flush();
}

Here is the EJB client code:

...
Context jndiContext = getInitialContext();
Object ref = jndiContext.lookup("java:EmployeeServiceBean/remote");
employeeService = (EmployeeServiceRemote) PortableRemoteObject.narrow(ref, EmployeeServiceRemote.class);
employeeService.changeSalary(45, 2l);
...

Here is the jndi.properties file:

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming rg.jnp.interfaces
java.naming.provider.url=jnp://localhost:1099

[Jaikiran Pai]

Can you post the entire exception stacktrace?

[John King]

If I commented off the entityManager.flush(), I would not get the exception, but the change would not be made in DB.

Here is exceptions on the client caused by the entityManager.flush():
---------------------------------


javax.ejb.EJBException: javax.persistence.TransactionRequiredException: no transaction is in progress
at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:63)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:95)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:304)
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:769)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:573)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:373)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)

Caused by: javax.persistence.TransactionRequiredException: no transaction is in progress
at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:293)
at org.jboss.ejb3.entity.TransactionScopedEntityManager.flush(TransactionScopedEntityManager.java:211)
at com.abc.ejb3.jpa.test.ejb.EmployeeServiceCmtxBean.changeSalary(EmployeeServiceCmtxBean.java:49)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:95)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:304)
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:769)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:573)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:373)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:163)
at org.jboss.remoting.Client.invoke(Client.java:1634)
at org.jboss.remoting.Client.invoke(Client.java:548)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:67)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:107)
at $Proxy0.changeSalary(Unknown Source)
at com.abc.ejb3.client.test.EJB3Client.testCmtxEJB(EJB3Client.java:51)
at com.abc.ejb3.client.test.EJB3Client.main(EJB3Client.java:24)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:67)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:107)
at $Proxy0.changeSalary(Unknown Source)
at com.abc.ejb3.client.test.EJB3Client.testCmtxEJB(EJB3Client.java:51)
at com.abc.ejb3.client.test.EJB3Client.main(EJB3Client.java:24)
[ May 25, 2008: Message edited by: John King ]

[Cameron Wallace McKenzie]

My guess, and this is only a guess, is that one of these two method calls is closing or committing the transaction:

  
Employee empEntity = this.entityManager.find(Employee.class, id);
empEntity.setSalary(salary);  

Any chance? What are the transactional attributes on setSalary and find? Any way that they are performing a commit on the current transaction?

Neat Tutorial on Transaction Annotations & TransactionAttributeType.REQUIRED

-Cameron McKenzie

[John King]

I'm letting the container to manage the transaction. This is the session bean:

@Stateless
@TransactionManagement(TransactionManagementType.CONTAINER)
public class EmployeeServiceCmtxBean implements EmployeeServiceCmtxRemote
{
@PersistenceContext(unitName="my_unit")
EntityManager entityManager;

@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void changeSalary(int id, long salary) throws IOException
{
Employee empEntity = this.entityManager.find(Employee.class, id);
empEntity.setSalary(salary);
entityManager.flush();
}
}

There is no change made into DB no matter I use entityManager.flush() or not. It seems that the empEntity is detached.

If I comment off entityManager.flush(), there would be no exceptions on the client side.

If I replace entityManager.flush() with entityManager.merge(empEntity), there is no change made into DB and no exceptions on client, but a warning on the server side:
WARN [AbstractEntityManagerImpl] Calling joinTransaction() on a non JTA EntityManager

If I change the code as:

Employee empEntity = this.entityManager.find(Employee.class, id);
empEntity.setSalary(salary);
entityManager.merge(empEntity);
entityManager.flush();

I will get both the client side exceptions and the server side warning.
[ May 25, 2008: Message edited by: John King ]

[Jaikiran Pai]

WARN [AbstractEntityManagerImpl] Calling joinTransaction() on a non JTA EntityManager

What does your persistence.xml look like? By any chance, are you using resource-local instead of the default JTA entitymanager?

P.S: While posting the logs or xml content or code, remember to wrap it in a code block using the Code button in the message editor window

[John King]

Here is the persistence.xml I used:

    
<?xml version="1.0" encoding="UTF-8"?>
<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 <a href="http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"" target="_blank" rel="nofollow">http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"</a> version="1.0">
<persistence-unit name="emp_proj" transaction-type="RESOURCE_LOCAL">
   <provider>org.hibernate.ejb.HibernatePersistence</provider>
   <non-jta-data-source>java:/OracleTestDS</non-jta-data-source>
   <properties>
      <property name="hibernate.dialect" value="org.hibernate.dialect.Oracle10gDialect"/>
      <property name="hibernate.cache.use_second_level_cache" value="false"/>
      <property name="hibernate.cache.use_first_level_cache" value="false"/>
      <property name="hibernate.cache.use_query_cache" value="false"/>  
   </properties>
</persistence-unit>
</persistence>

I tried to add additional persistence-unit in persistence.xml that uses JTA
as

    
<persistence-unit name="jta_emp_proj" transaction-type="JTA" >
   <provider>org.hibernate.ejb.HibernatePersistence</provider>
   <jta-data-source>java:/JTA_OracleTestDS</jta-data-source>
       <properties>
       <property name="hibernate.dialect" value="org.hibernate.dialect.Oracle10gDialect"/>
            <property name="hibernate.cache.use_second_level_cache" value="false"/>
            <property name="hibernate.cache.use_first_level_cache" value="false"/>
            <property name="hibernate.cache.use_query_cache" value="false"/>
       </properties>
</persistence-unit>

But I got these messages in the server log about the second persistence-unit:

--- MBeans waiting for other MBeans ---
ObjectName: persistence.units:jar=ejb3jpatest.jar,unitName=jta_emp_proj
State: NOTYETINSTALLED
I Depend On:
jboss.jca:name=JTA_OracleTestDS,service=DataSourceBinding
Depends On Me:
jboss.j2ee:jar=ejb3jpatest.jar,name=EmployeeServiceCmtxBean,service=EJB3

ObjectName: jboss.j2ee:jar=ejb3jpatest.jar,name=EmployeeServiceCmtxBean,service=EJB3
State: NOTYETINSTALLED
I Depend On:
persistence.units:jar=ejb3jpatest.jar,unitName=jta_emp_proj

--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
ObjectName: jboss.jca:name=JTA_OracleTestDS,service=DataSourceBinding
State: NOTYETINSTALLED
Depends On Me:
persistence.units:jar=ejb3jpatest.jar,unitName=jta_emp_proj

The following is my JBoss datasource file (oracle_test-ds.xml)

   
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<jta-datasource>
      <jndi-name>JTA_OracleTestDS</jndi-name>
      <connection-url>
jdbc :-o	 racle:thin:@localhost:1521:XE
      </connection-url>
      <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
      <user-name>uid</user-name>
      <password>pw</password>
      <min-pool-size>1</min-pool-size>
      <max-pool-size>3</max-pool-size>
      <idle-timeout-minutes>15</idle-timeout-minutes>
      <new-connection-sql>
SELECT 'new connection' FROM dual
      </new-connection-sql>
      <check-valid-connection-sql>
SELECT 'connection from pool' FROM dual
      </check-valid-connection-sql>
 
      <track-statements/>
      <metadata>
         <type-mapping>Oracle10g</type-mapping>
      </metadata>
</jta-datasource>
 
<local-tx-datasource>
      <jndi-name>OracleTestDS</jndi-name>
      <connection-url>
jdbc :-o	 racle:thin:@localhost:1521:XE
      </connection-url>
      <!-- The driver class -->
      <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
      <user-name>uid</user-name>
      <password>pw</password>
      <min-pool-size>1</min-pool-size>
      <max-pool-size>3</max-pool-size>
 
      <idle-timeout-minutes>15</idle-timeout-minutes>
 
      <new-connection-sql>
SELECT 'new connection' FROM dual
      </new-connection-sql>
      
      <check-valid-connection-sql>
SELECT 'connection from pool' FROM dual
      </check-valid-connection-sql>
      <track-statements/>
      <metadata>
         <type-mapping>Oracle10g</type-mapping>
      </metadata>
</local-tx-datasource>
</datasources>

[Jaikiran Pai]

Let the persistence.xml use JTA transaction-type.

Originally posted by John King:


The following is my JBoss datasource file (oracle_test-ds.xml)

   
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
[B]<jta-datasource>[/B]
      <jndi-name>JTA_OracleTestDS</jndi-name>
      <connection-url>
jdbc:oracle:thin:@localhost:1521:XE
      </connection-url>
      <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
      <user-name>uid</user-name>
      <password>pw</password>
      <min-pool-size>1</min-pool-size>
      <max-pool-size>3</max-pool-size>
      <idle-timeout-minutes>15</idle-timeout-minutes>
      <new-connection-sql>
SELECT 'new connection' FROM dual
      </new-connection-sql>
      <check-valid-connection-sql>
SELECT 'connection from pool' FROM dual
      </check-valid-connection-sql>
 
      <track-statements/>
      <metadata>
         <type-mapping>Oracle10g</type-mapping>
      </metadata>
[B]</jta-datasource>[/B]
 
<local-tx-datasource>
      <jndi-name>OracleTestDS</jndi-name>
      <connection-url>
jdbc:oracle:thin:@localhost:1521:XE
      </connection-url>
      <!-- The driver class -->
      <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
      <user-name>uid</user-name>
      <password>pw</password>
      <min-pool-size>1</min-pool-size>
      <max-pool-size>3</max-pool-size>
 
      <idle-timeout-minutes>15</idle-timeout-minutes>
 
      <new-connection-sql>
SELECT 'new connection' FROM dual
      </new-connection-sql>
      
      <check-valid-connection-sql>
SELECT 'connection from pool' FROM dual
      </check-valid-connection-sql>
      <track-statements/>
      <metadata>
         <type-mapping>Oracle10g</type-mapping>
      </metadata>
</local-tx-datasource>
</datasources>

The -ds.xml looks incorrect. Change it as follows (note, the use of local-tx-datasource for JTA_OracleTestDS):

   
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
[B]<local-tx-datasource>[/B]
      <jndi-name>JTA_OracleTestDS</jndi-name>
      <connection-url>
jdbc:oracle:thin:@localhost:1521:XE
      </connection-url>
      <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
      <user-name>uid</user-name>
      <password>pw</password>
      <min-pool-size>1</min-pool-size>
      <max-pool-size>3</max-pool-size>
      <idle-timeout-minutes>15</idle-timeout-minutes>
      <new-connection-sql>
SELECT 'new connection' FROM dual
      </new-connection-sql>
      <check-valid-connection-sql>
SELECT 'connection from pool' FROM dual
      </check-valid-connection-sql>
 
      <track-statements/>
      <metadata>
         <type-mapping>Oracle10g</type-mapping>
      </metadata>
[B]</local-tx-datasource>[/B]
 
<local-tx-datasource>
      <jndi-name>OracleTestDS</jndi-name>
      <connection-url>
jdbc:oracle:thin:@localhost:1521:XE
      </connection-url>
      <!-- The driver class -->
      <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
      <user-name>uid</user-name>
      <password>pw</password>
      <min-pool-size>1</min-pool-size>
      <max-pool-size>3</max-pool-size>
 
      <idle-timeout-minutes>15</idle-timeout-minutes>
 
      <new-connection-sql>
SELECT 'new connection' FROM dual
      </new-connection-sql>
      
      <check-valid-connection-sql>
SELECT 'connection from pool' FROM dual
      </check-valid-connection-sql>
      <track-statements/>
      <metadata>
         <type-mapping>Oracle10g</type-mapping>
      </metadata>
</local-tx-datasource>
</datasources>

[ May 27, 2008: Message edited by: Jaikiran Pai ]

[John King]

It fixes the problem. What is jta-datasource for? Distributed transaction?

[Jaikiran Pai]

Originally posted by John King:
What is jta-datasource for? Distributed transaction?[/QB]

A jta-datasource is capable of participating in a transaction which follows the JTA (Java Transaction API) spec.