"ARJUNA016108: Wrong transaction on thread" whennested transactions throws Exception #13776
Comments
ghost
added
the
|
When a JTA transaction is started it gets associated with the calling thread (this is in the JTA spec). If you start a second transaction while that one is running and still associated then we throw a javax.transaction.NotSupportedException. JTA transaction management is normally performed by frameworks and the usual behaviour is to suspend the original transaction before starting another one. We do support nested transactions but you have to enable them but, even then, frameworks such as EBJ and JPA do not handle nested transactions. |
|
@mmusgrov The "Wrong transaction on thread" is already fixed by #13855. Main problem was, that in case of an exception the suspended transaction never got activated again. Only thing really remaining is that narayana is logging the exception as warning. I believe that this log should at least not include the full exception, since the exception itself is rethrown and is then logged by quarkus. |
What about the alternate viewpoint that it should be the responsibility of quarkus not to re-throw the exception. Changing it in Narayana means that other systems we integrate with would not see the stacktrace. Is the quarkus code that re-throws it in the JTA extension or is it happening elsewhere, if it under quarkus's control then it ought to be done there? |
|
Ah wait, you said that we were re-throwing it and that quarkus then logs it again. I would still argue that an alternate viewpoint is that quarkus log only the message if it thinks the full stack has already been logged. If you still think we should not log the full stack then we would need input from the various narayana jta transaction stakeholders. For that you could raise the issue on our forum https://groups.google.com/g/narayana-users, that way we can get input from a wider audience than just quarkus. |
|
Is this still an issue? |
|
Closing for lack of feedback |
Describe the bug
I have nested transactions in my applications. The service has its own transaction (REQUIRES_NEW). It calls a helper class also having a REQUIRES_NEW.
If for any reason the nested transaction throws a PersistenceException (for example, optimisticlocking, or field value too big), I get multiple log outputs which are not correct in my opinion.
"SqlExceptionHelper" just logs the exception getMessage.
"com.arj.ats.arjuna" just logs the PersistenceException as a warn. #13854
I then catch the PersistenceException in "org.acm.ExampleSchedulerService" - this would normally lead to an additional error log.
After all these logs, an "java.lang.RuntimeException: ARJUNA016108: Wrong transaction on thread" RuntimeException is thrown.You can "fix" this message, if you remove the Transactional from ExampleSchedulerService.
At the end, I also get messages from the transaction reaper. It might be that the outer transaction is never closed correctly.(fixed by #13855)
Expected behavior
These logs may be a bit too much, since they all just contain the same information. I expected to only have a catchable PersistenceException.
Additionally, the "ARJUNA016108" may need to get fixed inside quarkus.
I attached my debugger at this position:
quarkus/extensions/narayana-jta/runtime/src/main/java/io/quarkus/narayana/jta/runtime/interceptor/TransactionalInterceptorBase.java
Lines 304 to 306 in 0de5731
and noticed that tm.getTransaction() returned null. Is the outer transaction closed after the inner one is rolled back?
Actual behavior
To Reproduce
Steps to reproduce the behavior:
Environment (please complete the following information):
uname -aorver:MSYS_NT-10.0 NANB7NLNVP2 2.10.0(0.325/5/3) 2018-06-13 23:34 x86_64 Msys
mvnw --versionorgradlew --version):Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: C:\eclipse\tools\apache-maven\bin..
Java version: 11.0.7, vendor: Azul Systems, Inc., runtime: C:\eclipse\tools\zulu11.39.15-ca-jdk11.0.7-win_x64
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
The text was updated successfully, but these errors were encountered: