[ http://jira.jboss.com/jira/browse/JBJTA-1?page=history ]
Adrian Brock updated JBJTA-1:
-----------------------------
Description:
Implement optional transaction recovery
The simplest mechanism is to do this is with a local database
using the last resource gambit where during its "prepare" it logs the XID in a
table.
If this last resource fails to commit, recovery will not find the transaction
in the table which means it will rollback the whole transaction.
This has limitations where a different local resource is required within the
transaction
but not this local database used as the recovery log.
Another implementation is a local file. Though more complicated it should give
superior
performance.
But, it does not work well with the last resource gambit, e.g. you cannot tell
whether the jdbc commit() suceeded or failed if it crashes just at the point of
this invocation
before the result is returned from the db.
The other work required:
1) Possibly, simplify the dependencies in the JCA module so we can run the
recovery earlier.
Currently the RARs need the transaction manager at deployment time. The
recovery service needs to be an external service depending upon both the
tm and the managed connection factories.
At least this will require a GUID for the XID so we can avoid duplicates between
unrecovered XIDs and any new XIDs created before recovery is complete.
2) JBossMQ needs to implement XAResource.recover()
was:
Implement optional transaction recovery
The simplest mechanism is to do this is with a local database
using the last resource gambit where during its "prepare" it logs the XID in a
table.
If this last resource fails to commit, recovery will not find the transaction
in the table which means it will rollback the whole transaction.
This has limitations where a different local resource is required within the
transaction
but not this local database used as the recovery log.
Another implementation is a local file. Though more complicated it should give
superior
performance.
But, it does not work well with the last resource gambit, e.g. you cannot tell
whether the jdbc commit() suceeded or failed if it crashes just at the point of
this invocation
before the result is returned from the db.
The other work required:
1) Possibly, simplify the dependencies in the JCA module so we can run the
recovery earlier.
Currently the RARs need the transaction manager at deployment time. The
recovery service needs to be an external service depending upon both the
tm and the managed connection factories.
At least this will require a GUID for the XID so we can avoid duplicates between
unrecovered XIDs and any new XIDs created before recovery is complete.
2) JBossMQ needs to implement XAResource.recover()
Environment:
JBoss Forum Reference:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=58285
> Transaction Recovery
> --------------------
>
> Key: JBJTA-1
> URL: http://jira.jboss.com/jira/browse/JBJTA-1
> Project: JBoss JTA
> Type: Task
> Reporter: Adrian Brock
>
>
> Implement optional transaction recovery
> The simplest mechanism is to do this is with a local database
> using the last resource gambit where during its "prepare" it logs the XID in
> a table.
> If this last resource fails to commit, recovery will not find the transaction
> in the table which means it will rollback the whole transaction.
> This has limitations where a different local resource is required within the
> transaction
> but not this local database used as the recovery log.
> Another implementation is a local file. Though more complicated it should
> give superior
> performance.
> But, it does not work well with the last resource gambit, e.g. you cannot tell
> whether the jdbc commit() suceeded or failed if it crashes just at the point
> of this invocation
> before the result is returned from the db.
> The other work required:
> 1) Possibly, simplify the dependencies in the JCA module so we can run the
> recovery earlier.
> Currently the RARs need the transaction manager at deployment time. The
> recovery service needs to be an external service depending upon both the
> tm and the managed connection factories.
> At least this will require a GUID for the XID so we can avoid duplicates
> between
> unrecovered XIDs and any new XIDs created before recovery is complete.
> 2) JBossMQ needs to implement XAResource.recover()
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
JBoss-Development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-development
