Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

An illegal attempt to commit a one phase capable resource with existing two phase capable resources

Ranch Hand
Posts: 446
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am facing one weird issue in WebSphere. The same code works fine in WebLogic 7.0 SP5 but fails in WebSphere

I have a MDB with Transaction Attribute set as "NOT_SUPPORTED".

This MDB calls three different Stateless Session Beans say BeanA, BeanB, and BeanC. All three EJBs write to three different data sources.

The transaction attribute of BeanA is "REQUIRED" and that of BeanB and BeanC is "REQUIRES NEW".

The transaction management for all 4 EJBs is container managed. The LTC (Local Transaction Containment for BeanA, BeanB, and BeanC is MethodBoundary).

When onMessage() method of MDB gets called, the only exception I see is following.

WTRN0063E: An illegal attempt to commit a one phase capable resource with existing two phase capable resources has occurred.
WTRN0086I: XAException encountered during prepare phase for transaction 0000012A2597D71B00000001000000223093AA362DAC435BD399143CA63A56D26A92F4670000012A2597D71B00000001000000223093AA362DAC435BD399143CA63A56D26A92F46700000001. Local resources follow.
WTRN0089I: LocalTransactionWrapper@:26bd26bd enlisted:trueHas Tran Rolled Back = false registeredForSynctruemcWrapper.hashcode()604775436: Vote: none.
WTRN0089I: [ <> <meName=003HAYASDG409Node01.devMAAPServer-MAAPSIB> <meUuid=93EF716521FD5795> <busName=MAAPSIB> <xaRecoveryAlias=null> <userName=null> <password=null> <recoveryToken=3> <useServerSubject=false> <providerEndpoints=null>]: Vote: commit.

I am using EJB3 annotations to declare the transaction attributes in the bean source files.
I think for some weird reasons the transaction attribute of MDB stays as "REQUIRED", which is causing the above issue.

Interestingly if I change the transaction management of MDB from Container managed to Bean managed then above method works fine. I don’t see any exceptions and data sources are getting updated properly.
Deepak Pant
Ranch Hand
Posts: 446
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have figured out the problem.

We have about 7 different MDBs in our application, all of which extend a common base class.

This base class implements onMessage() method and in turn calls an abstract method, which is implemented by the child beans (7 MDB classes).

We did this to have a central controller class, which can receive the onMessage() call, perform some pre and post logic and then delegate the call to the child classes.

All the child MDB classes have the proper annotations ("@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)" but for some reason WAS ignores it because the only method it is looking for (onMessage in this case) is present in the base class. So it assigns the default transaction attribute of TX_REQUIRED causing our logic to fail.

I did try putting the annotation on top of the method in the base class but it didnt work either. So finally I renamed the base class method to something else and implemented onMessage() in all the child MDBs and the problem goes away. The trace shows proper transaction attribute in all the MDBs (TX_NOT_SUPPORTED in 5 classses and TX_REQUIRED in 2 classes).

This feature worked fine in WebLogic server as it would pick the annotation (or the information from ejb-jar.xml/assembly descriptor) and apply it to the public method present in the MDB class. (Whether it came from the child bean or the parent bean)
Not so fast naughty spawn! I want you to know about
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic