[jboss-jira] [JBoss JIRA] (WFLY-3801) Wrong Transaction behaviour for EJBs if JTS is enabled

[Scott Marlow (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13014594#comment-13014594 ] 

Scott Marlow commented on WFLY-3801:
------------------------------------

I checked other persistence providers and they also check the transaction status.  One of them does cache the status passed to their afterCompletion call but they can still call Transaction.getStatus() as well (in other internal classes called from their afterCompletion).

As a general practice, I'm not sure that Hibernate would want to cache the transaction status, since it could change at any time.  In the afterCompletion case, the tx status won't change but I think we need to hear that there will be signficant performance gains made by that change (in the Hibernate afterCompletion call, not the EE JPA container sync afterCompletion call).  Like I said before, I will ask the Hibernate team if they can avoid calling getStatus in some future Hibernate version of their EntityManager.close() implementation.  Of course, the older versions would still call getStatus, so this only reduces the problem but doesn't eliminate the excessive logging.

Another point of view, is that the warning should only be logged from UserTransaction.getStatus(), as we are currently warning our end users that have developed applications using our transaction manager, that the system developers called the wrong thing (thousands of times, over and over, until the poor user disables the warning).  System developers should call TransactionManager.getStatus but not applications.  IMO, moving the logging to UserTransaction.getStatus() would target the application developers better.  


> Wrong Transaction behaviour for EJBs if JTS is enabled
> ------------------------------------------------------
>
>                 Key: WFLY-3801
>                 URL: https://issues.jboss.org/browse/WFLY-3801
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Transactions
>    Affects Versions: 8.1.0.Final
>         Environment: standalone-full profile with JTS enabled
>            Reporter: Wolf-Dieter Fink
>            Assignee: David Lloyd
>         Attachments: 456a624-withDestroy.log, 8d49872-error.log, enableJTS.cli, reproducer.zip, server.log
>
>
> If JTS is enabled the invocation of EJB's might show a arjuna warning for each method invocation:
>    WARN  [com.arjuna.ats.jts] (RequestProcessor-5) ARJUNA022261: ServerTopLevelAction detected that the transaction was inactive
> This is only the case if other resources are involved, i.e. a DB via JPA.
> If a simple bean is used (like ejb-remote quickstart) this warning is not shown.
> It looks like the transaction is local commited but in case of a SFSB @Remove method the result is a " WFLYEE0006: Failed to destroy component instance  Instance of SFTestBean" and the lifecycle method @PreDestroy is not invoked.



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)