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):
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
Added relevant information to the upstream JIRA.
Ivo Studensky <email@example.com> updated the status of jira WFLY-4608 to Closed