Named Query and Native Query: Transaction issue

[anelsonwilson]

Hi All,

I am writing a simple java function which contains many NamedQuery, but in one place I have wrote a NativeQuery as the query is very complex.

I am facing the transaction issue here.

As I have wrote the NativeQuery, its not comming in the same transaction hierarchy of the NamedQuery is maintaining. Means NativeQuery is considering its transaction as an separate query.

What should I do to make this NativeQuery to maintain its transaction.

Any help is appreciated.

Configurations:

WildFly 8.1.0

EJB3.1

JDK 1.7

JPA (Hibernate provider)

Thanking You.

[smarlow]

In the application JTA transaction, is there any other JPA activity?  I am especially interested in how many different JPA persistence units are used in the transaction.

If your not sure, you could enable TRACE logging for JPA, Hibernate, Arjuna as mentioned here

If you are using more than one persistence unit per transaction, you are likely hitting the delist bug (only first persistence unit is enlisted in transaction, other persistence units may be delisted).  Before we assume your hitting that, lets see what you find in answer to the above questions.

[anelsonwilson]

Hi Scott,

First of all, Thanks for your response.

Here in our application we are using just one JPA persistance unit.

Our architectural design is as follows:-

1) UI Layer

2) Service Layer

3) DAO Layer

Here user request is coming to Service layer.Service layer has one function, its a very complex function. From this function we are making many calls to DAO layer. In most of our call to DAO we have written JPA NamedQuery but at some places, because the query is very complex, we have used Native Queries.

Here we are facing transactional issue. When there is any rollback, the JPA queries gets rolled back but Native query gets committed. I have read some where and there it was mentioned that JPA query and Native query maintains a separate transactional states. So how should I maintain the Native queries' transaction with the JPA queries.

Is there any way to overcome this problem in WildFly 8.1.0 ?

Please help.

Thanking You.

[smarlow]

Even though you have only one persistence unit, I am wondering if you could be hitting a problem where the xa resource is delisted from the the JTA transaction.  Others hit this issue when they used more than one persistence unit per JTA transaction (see https://issues.jboss.org/browse/WFLY-3619).

A pull request for the WFLY-3619 issue has been created for WildFly 8.2 but not yet merged in (https://github.com/wildfly/wildfly/pull/6717).

I am thinking that you should jump into the low details, of enabling TRACE logging and examining the output for one JTA transaction where you have this problem.  The trace output should show the enlist/delist as well as other details of what exactly is occurring.  Some documentation to help get you started is at https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide#JPAReferenceGuide-Troubleshooting

Scott