Bug 1036040 - Calling EJB with "REQUIRES_NEW" transaction attribute creates two transactions.
Summary: Calling EJB with "REQUIRES_NEW" transaction attribute creates two transactions.
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: EJB
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: EAP 6.4.0
Assignee: Ivo Studensky
QA Contact: Ondrej Chaloupka
Russell Dickenson
Depends On:
TreeView+ depends on / blocked
Reported: 2013-11-29 09:12 UTC by Hayk Hovsepyan
Modified: 2016-02-24 13:48 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
In this release of JBoss EAP 6, an issue in the EJB component causes transaction statistics to show an incorrect number of processed transactions. This is becuase the `CMTTxInterceptor` and `LifecycleCMTTxInterceptor` interceptors create two transactions when handling EJB requests. One is a dummy transaction and other is used for managing resources. This results in the one EJB request being counted twice in statistics. There is no workaround available at this time.
Clone Of:
Last Closed: 2016-02-24 13:48:28 UTC
Type: Bug

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1017256 None None None Never
Red Hat One Jira Issue Tracker WFLY-4608 Major Closed Omit no-op transaction if lifecycle method is missing 2017-11-08 20:22:32 UTC

Internal Links: 1017256

Description Hayk Hovsepyan 2013-11-29 09:12:12 UTC
Description of problem:
"number-of-committed-transactions" attribute in transaction statistics is greater by 1 rather than the expected value.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Read the "number-of-committed-transactions" attribute's value.
2. Enable transaction statistics.
3. Remotely call transactional method (REQUIRES_NEW) which commits.
4. Read the "number-of-committed-transactions" attribute's value. It must be increased by 1, but in fact it is increased by 2.

Steps to Reproduce 2:
1. Read the "number-of-committed-transactions" and the "number-of-aborted-transactions" attributes values.
2. Enable transaction statistics.
3. Remotely call transactional method (REQUIRES_NEW) which rollbacks, for example throws custom ApplicationException with rollback=true.
4. Read the "number-of-committed-transactions" attribute's value. It must not be increased, but in fact it is increased by 1.
5. Read the "number-of-aborted-transactions" attribute's value. It is increased by 1, which is correct.

Actual results:
when calling only 1 transactional method which commits, "number-of-committed-transactions" attribute's value is increased by 2.
when calling only 1 transactional method which rollbacks, "number-of-committed-transactions" attribute's value is increased by 1.

Expected results:
when calling only 1 transactional method which commits, "number-of-committed-transactions" attribute's value must be increased by 1.
when calling only 1 transactional method which rollbacks, "number-of-committed-transactions" attribute's value must not be increased.

Additional info:
when 3 commits, "number-of-committed-transactions" is increased by 4.
when 1 commit and 1 rollback, "number-of-committed-transactions" is increased by 2.

Comment 1 Gytis Trikleris 2014-08-06 08:49:08 UTC
After debugging this problem, I can conclude that this is not an issue with transaction statistics. There are actually two transactions created by the interceptors handling EJB request. Interceptors which do that are CMTTxInterceptor and LifecycleCMTTxInterceptor.

CMTTxInterceptor is invoked first and creates a new transaction, since there is no active transaction at the moment. Later on in a chain LifecycleCMTTxInterceptor is invoked. Since we have REQUIRES_NEW attribute on our bean, interceptor suspends active transaction and creates a new one.

Additionally, changing transaction attribute from REQUIRES_NEW to REQUIRED does not help either. It is because LifecycleCMTTxInterceptor factory has treatRequiredAsRequiresNew attribute which is hard coded to true by StatelessComponentDescription which uses the factory.

Comment 2 Hayk Hovsepyan 2014-08-06 09:54:35 UTC
Reassigning this bug to EJB component. As calling EJB beans with "REQUIRES_NEW" transaction attribute can cause statistics to show more results than expected.
The severity of this bug depends on how active the customers are using statistics.

Comment 3 tom.jenkinson 2014-08-06 10:10:35 UTC

I think we should update the description and summary (or use a different bug and link it to this).

The issue is the creation and completion of the unused transaction. The actual total number of transactions reported by stats _is_ correct, its just that a no-op tx is created in this use case.


Comment 4 Ondrej Chaloupka 2014-08-06 10:52:06 UTC
Hi Tom, Hi Hayk,

I see your point but I would like to emphasize the optics that me, as dummy EAP user, understand the statistics.
I would not care what my ejb does internally I would like know how much transactions were proceeded in my business case. From that point of view the statistics shows incorrect numbers and stats shown by EAP console is not correct.
I think that no-op transactions should not be counted as they are, in fact, not valid transactions from customer point of view.

Just my thoughts.


Comment 5 tom.jenkinson 2014-08-06 11:05:55 UTC
Thanks for the input Ondra!

To confirm, the stat we have provided is a Narayana specific counter of the number of times commit/rollback completes successfully or not. We can certainly look at providing alternative stat mechanisms but those would come via community/customer feedback I think (f.ex if you would find it useful, create a discussion on the forum).

As an example of why the current stat is how it is, consider what TxStats::getNumberOfTransactions() should return (its incremented at the moment during "begin()")? Would you imagine it only increment for transactions when they had a resource enlisted? Or maybe have had a synchronization enlisted? Or marked set rollback only?

The stat that you propose sounds more like a business transaction than a Narayana transaction but I am not altogether sure. The number of cases where no-op tx's are created should be limited and possibly would improve performance to resolve those scenarios.

Comment 6 Ondrej Chaloupka 2014-08-06 15:28:17 UTC
Hi Tom,

thanks for more ideas and explanation. I wasn't checking the code.

I have no idea how customers use statistics but if they use it I think they care about the "business transaction" statistics. And more precisely said I think they expect that the number which is shown in EAP console is related to "business transactions". They don't expect that numbers there shown some eap internal transactions. It seems to me that current numbers are bit useless for any user. But I could be wrong.

I'm fully in agreement with you that if there should be some alternative stat mechanism added then it should come via community/customer feedback. 

I'm thinking about creating a bugzilla for documentation to put some note what the statistics show now. 

It seems to me an interesting point about no-op tx and performance impact.
If I may ask, do you think David, that no-op tx could be removed? And could it  increase performance?

Comment 7 Ondrej Chaloupka 2015-03-05 14:22:33 UTC
Adding doc text flag to ? as I think this "special" output of transaction statistics should be mentioned in release notes.
I mean that some transactions are counted twice and the statistics shows just general overview of transaction processing but the precise numbers are a bit misleading.

Comment 9 David M. Lloyd 2015-11-16 12:43:01 UTC
Added relevant information to the upstream JIRA.

Comment 10 JBoss JIRA Server 2015-12-02 13:35:20 UTC
Ivo Studensky <istudens@redhat.com> updated the status of jira WFLY-4608 to Closed

Note You need to log in before you can comment on or make changes to this bug.