EJB 2.1 BMP with CMT and RequiresNew in JBoss AS 7.1.0 Final

[dzhelyazkov]

I have the folowing case where transactions lock up, and it was working OK in JBoss 3, 4 and 6.

We have the Session Facade pattern where the SLSB calls the Entity Bean, both SLSBs and EntityBeans use RequiresNew as transaction attribute. (Changing the Entity Beans attribute to Requires solves the problem, too much places to fix, and some tricky situations where more changes are required)

So what happens is:

SLSB.newRecord(...) starts with RequiresNew

{

    //with RequiresNew (the insert statement is executed, then by spec on TX end ejbLoad is called and data is read from Database - so far so good.

     record = EntityHome.create(...);

     //method part of the local interface of the Entity - here a new transaction is started, and at the end of the method the transacion is commited and ejbStore is called, however this does not work because of db lock which I can not understand.

   record.getProperties(); 

}

The datasource isolation level is READ_COMMITED.

In previous versions of JBoss call to record.getProperties() did not start new transaction and no call to ejbStore

I hope someone could help,

Daniel

[dzhelyazkov]

Turns out I was wrong, the Entity Bean was recently changed to Requres. So what happens is this

SLSB starts TX1

Entity creates record within TX1

record.getProperties() starts new TX2 and calls update and commit at end of TX2, and here lock happens

the question remains why record.getProperties() spawns new TX

Edit: the Bean was not changed to Required. I was mislead by the fact that in reallity JBoss uses Required even though it is RequiresNew!

	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:293)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:190)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$2.processInvocation(EjbExceptionTransformingInterceptorFactories.java:89)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:173)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
	at ejb.entity.RoleHome$$$view207.create(Unknown Source)
	at ejb.session.RoleFacadeBean.newRole(RoleFacadeBean.java:117)

after Entity.create(...) is executed the record is not visible in DB, so it may really be using Required.

daniel

[dzhelyazkov]

Fixed my problem, after debug session of JBoss code it turned out that the code that parses TX attributes produces wrong info.

we had the folowing in ejb-jar.xml

<method>

     <ejb-name>SomeEjb</ejb-name>

     <method-name>*</method-name>

</method>

...

<trans-attribute>RequiresNew</trans-attribute>

Specified like that JBoss set default TX attribute Required to all LOCAL_HOME methods (ejbCreate/Find/Select/Home)

and RequiresNew to all Bean methods such as toString(), hashCode()...

by adding <method-intf>LocalHome</method-intf>

<method>

     <ejb-name>SomeEjb</ejb-name>

     <method-intf>LocalHome</method-intf>

     <method-name>*</method-name>

</method>

all went to normal, my ejbCreate() started new transaction, and getProperties() method did not use TX interceptor.

So it looks like different or wrong loginc in JBoss, the code itself states it has some problems, and it looks targeted at EJB 3.x, it is not a separate code for 2.x

daniel

[jaikiran]

Daniel Zhelyazkov wrote:

Fixed my problem, after debug session of JBoss code it turned out that the code that parses TX attributes produces wrong info.

we had the folowing in ejb-jar.xml

<method>

     <ejb-name>SomeEjb</ejb-name>

     <method-name>*</method-name>

</method>

...

<trans-attribute>RequiresNew</trans-attribute>

Specified like that JBoss set default TX attribute Required to all LOCAL_HOME methods (ejbCreate/Find/Select/Home)

and RequiresNew to all Bean methods such as toString(), hashCode()...

by adding <method-intf>LocalHome</method-intf>

<method>

     <ejb-name>SomeEjb</ejb-name>

     <method-intf>LocalHome</method-intf>

     <method-name>*</method-name>

</method>

all went to normal, my ejbCreate() started new transaction, and getProperties() method did not use TX interceptor.

So it looks like different or wrong loginc in JBoss, the code itself states it has some problems, and it looks targeted at EJB 3.x, it is not a separate code for 2.x

daniel

Daniel, have you been able to reproduce this against the latest nightly build https://community.jboss.org/thread/167590 or maybe 7.1.1.Final?

[wdfink]

This is reproducable with EAP6.1.

I've created a bug for this https://bugzilla.redhat.com/show_bug.cgi?id=971284