Bug 1036040
| Summary: | Calling EJB with "REQUIRES_NEW" transaction attribute creates two transactions. | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Hayk Hovsepyan <hhovsepy> |
| Component: | EJB | Assignee: | Ivo Studensky <istudens> |
| Status: | CLOSED NOTABUG | QA Contact: | Ondrej Chaloupka <ochaloup> |
| Severity: | medium | Docs Contact: | Russell Dickenson <rdickens> |
| Priority: | unspecified | ||
| Version: | 6.2.0 | CC: | david.lloyd, istudens, ochaloup, smumford, tom.jenkinson |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | EAP 6.4.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-02-24 13:48:28 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Hayk Hovsepyan
2013-11-29 09:12:12 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. 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. Hi, 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. Tom 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 Ondra 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. 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? 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 <istudens> updated the status of jira WFLY-4608 to Closed |