Bug 1064170
| Summary: | Recovery problem on crash during prepare phase with TM running with JTS | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Ondrej Chaloupka <ochaloup> | ||||
| Component: | Transaction Manager | Assignee: | tom.jenkinson | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Ondrej Chaloupka <ochaloup> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.2.0 | CC: | smumford | ||||
| Target Milestone: | --- | ||||||
| Target Release: | TBD EAP 6 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-05-07 15:10:29 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: | |||||||
| Attachments: |
|
||||||
|
Description
Ondrej Chaloupka
2014-02-12 07:40:56 UTC
Hi Ondra, Sorry for the delay in responding to you, I have now completed my research and can confirm that this is working as expected. We do not automate orphan detection in the JTS case. There are two things to consider: 1. Is this fact documented? - if not we should raise a BZ 2. Do we want to add this? If so we need to get it in a PRD. Its not as straightforward as it seems as it is possible that we are using context propagation, rather than (the default) interposition and in that scenario there is no log written by the TM at that node. Hope that clarifies, Tom Hi Tom, thanks for the clarification. Just this could be unexpected behavior for users. Maybe... There is no documentation about this "limitation" (at least what I know). So I will raise a documentation BZ to have this info in the next EAP documentation release. Which should be probably docs for EAP 6.3.0. I see that this would not be simple fix. At the question whether we want it I'm not clear about it. I think that this behavior could cause some problems... When I would think about the database xa resource then after prepare is called the database started transaction and called prepare on it. Which means that when rollback is not called then the transaction could be hanging there for some time. But, as I understand, at that time there is created no locks on database content so further operations won't be influenced. Is that right? And do you think that there could be some other danger for the application workflow? In general from point of view how recovery works I would expect that the rollback should be called. Then it would be fine to have this fixed. Or am I wrong? Thanks Ondra Hi Ondra, Locks are indeed potentially held. However, a DBA is able to use the tooling to manually rollback those resources. Tom Hi Ondra, What would you like to do with this, I think it should be closed as the system is working as expected. I am happy if you want to raise a PRD item to get this feature added to a future version of the software? Do you add them to the EAP6 Jira? Tom The 6.3.0 flag was removed. I've put the target release to some feature EAP 6 release as from product specification the orphan detection is not supported for JTS. I've created a product jira feature request for this could be added in future: https://issues.jboss.org/browse/JBTM-2124 Thanks Hi Ondra, I think we should close the BZ as its not a product bug and just use the Jira until it makes a PRD. Are you OK with that? Thanks, Tom Agree. This is not a bug as the behavior is expected by JTS spec. The feature request was created (https://issues.jboss.org/browse/JBTM-2124) that the behavior could be consistent with JTA in future. |