]
Michael Musgrove commented on JBTM-2819:
----------------------------------------
I have clarified the semantics of clearing heuristics in the linked documentation issue.
QE are reworking the test to see if there is an issue with our handling of these types of
transaction.
Recover operation does not work for participant of JCA type
transactions
------------------------------------------------------------------------
Key: JBTM-2819
URL:
https://issues.jboss.org/browse/JBTM-2819
Project: JBoss Transaction Manager
Issue Type: Bug
Affects Versions: 5.4.0.Final
Reporter: Ondra Chaloupka
Assignee: Michael Musgrove
Attachments: heuristic-rollback-objectstore.zip
Jboss cli {{:recover}} operation does not work when having JCA type transaction. My test
shows following
{code}
[standalone@localhost:9990 /] /subsystem=transactions/log-store=log-store:probe
{"outcome" => "success"}
[standalone@localhost:9990 /]
/subsystem=transactions/log-store=log-store:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"expose-all-logs" => false,
"type" => "default",
"transactions" => {
"0:ffff7f000001:-4cecb39b:585109e2:31" => {
"age-in-seconds" => undefined,
"id" => "0:ffff7f000001:-4cecb39b:585109e2:31",
"jmx-name" => undefined,
"type" => "CosTransactions/XAResourceRecord",
"participants" => undefined
},
"0:ffff7f000001:-4cecb39b:585109e2:28" => {
"age-in-seconds" => "1481798762",
"id" => "0:ffff7f000001:-4cecb39b:585109e2:28",
"jmx-name" => undefined,
"type" =>
"StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA",
"participants" =>
{"0:ffff7f000001:-4cecb39b:585109e2:31" => {
"eis-product-name" => "unavailable",
"eis-product-version" => "unavailable",
"jmx-name" => undefined,
"jndi-name" =>
"0:ffff7f000001:-4cecb39b:585109e2:31",
"status" => "HEURISTIC_ROLLBACK",
"type" =>
"/StateManager/AbstractRecord/ExtendedResourceRecord"
}}
}
}
}
}
[standalone@localhost:9990 /]
/subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:recover
{"outcome" => "success"}
[standalone@localhost:9990 /]
/subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:read-resource
{
"outcome" => "success",
"result" => {
"eis-product-name" => "unavailable",
"eis-product-version" => "unavailable",
"jmx-name" => undefined,
"jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31",
"status" => "HEURISTIC_ROLLBACK",
"type" =>
"/StateManager/AbstractRecord/ExtendedResourceRecord"
}
}
{code}
I expect that {{:recover}} put the participant to {{PREPARED}} state and at that point
RAR {{XATerminator.commit}} could commit such participant.