[JBoss JIRA] Created: (JBTM-895) Expose an API that allows JTA to be controlled in a distributed manner
6:30 a.m.
Expose an API that allows JTA to be controlled in a distributed manner
----------------------------------------------------------------------
Key: JBTM-895
URL: https://issues.jboss.org/browse/JBTM-895
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Tom Jenkinson
Assignee: Tom Jenkinson
Priority: Blocker
Fix For: 4.15.x
This feature is requested by the Remoting team.
More details coming soon!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:05 p.m.
New subject: [JBoss JIRA] Updated: (JBTM-895) Expose an API that allows JTA to be controlled in a distributed manner
[
https://issues.jboss.org/browse/JBTM-895?page=com.atlassian.jira.plugin.s...
]
Tom Jenkinson updated JBTM-895:
-------------------------------
Description:
This feature is requested by the Remoting team.
Options are:
ClientUserTransaction requires no additional implementation work. The same hooks that
supported the earlier implementations of this can be used for the new one too.
Transaction context inflow support falls into two parts: whole transaction (gtrid)
interposition and branch only (bqual) interposition.
For whole transaction interposition, a new subordinate transaction context is created on
each node receiving an inflow. Synchronizations are handled purely locally. The JCA inflow
API can be used, albeit with semantics which IMO are not spec compliant. This model would
be relatively simple to implement on the transaction manager side, as the existing
recovery architecture will mostly still apply. IMO it's of limited utility for users
though, as resource managers will see independent transactions and not do any transaction
branch coupling. That impacts both functionality and performance.
For branch only transaction interposition, subordinate nodes maintain the inflowed gtrid
but create new branches within an allocated portion of the bqual state space. This
requires information about the allocation of bqual space to be communicated, either by
explicit parameter passing for the general case or by encoding in the Xid for the
jboss->jboss inflow case. It affords the opportunity for branch coupling in resource
managers used by more than one node in the same transaction, but leads to more complicated
recovery needs. Specifically recovery can no longer be driven off consideration of the
gtrid ownership alone, but must also consider bqual ownership. This naturally requires
that the bqual value actually contain node ownership information, which will require a new
encoding. On the other hand we probably need one anyhow to communicate delegation of the
bqual state space on links where we're working with 3rd party implementations and thus
constrained to the JCA api rather than one that could carry additional parameters. For
links where we do control both ends, we need additional methods to support afterCompletion
as a separate phase. BeforeCompletion is already available as a separate step on
subordinate transactions, although it may need to be even finer grained to allow for JTA
1.1 TSR sync interposition semantics to be transaction global rather than node local.
In both models the communication is entirely top down - the coordinator does not exist as
a network endpoint as in JTS, as persistent ids are not supported by the remoting
transport. This constrains recovery to use the XA recovery scan model rather than the JTS
replayCompletion one. One consequence of this is that parent nodes will require to
maintain a list of all possible subordinates and have a recovery module plugin for them,
but that's probably not an undue burden for most deployment scenarios. Another
consequence is that it's probably going to be better to build it as distributed hooks
into JBossJTA rather than a pluggable transport layer for JBossJTS. That should also offer
better performance as resource records will get inlined to the tx rather than be separate
ostore entries.
was:
This feature is requested by the Remoting team.
More details coming soon!
Forum Reference: http://community.jboss.org/thread/171004?tstart=0 (was:
http://community.jboss.org/thread/171004?tstart=0)
Expose an API that allows JTA to be controlled in a distributed
manner
----------------------------------------------------------------------
Key: JBTM-895
URL: https://issues.jboss.org/browse/JBTM-895
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Reporter: Tom Jenkinson
Assignee: Tom Jenkinson
Priority: Blocker
Fix For: 4.15.x
This feature is requested by the Remoting team.
Options are:
ClientUserTransaction requires no additional implementation work. The same hooks that
supported the earlier implementations of this can be used for the new one too.
Transaction context inflow support falls into two parts: whole transaction (gtrid)
interposition and branch only (bqual) interposition.
For whole transaction interposition, a new subordinate transaction context is created on
each node receiving an inflow. Synchronizations are handled purely locally. The JCA inflow
API can be used, albeit with semantics which IMO are not spec compliant. This model would
be relatively simple to implement on the transaction manager side, as the existing
recovery architecture will mostly still apply. IMO it's of limited utility for users
though, as resource managers will see independent transactions and not do any transaction
branch coupling. That impacts both functionality and performance.
For branch only transaction interposition, subordinate nodes maintain the inflowed gtrid
but create new branches within an allocated portion of the bqual state space. This
requires information about the allocation of bqual space to be communicated, either by
explicit parameter passing for the general case or by encoding in the Xid for the
jboss->jboss inflow case. It affords the opportunity for branch coupling in resource
managers used by more than one node in the same transaction, but leads to more complicated
recovery needs. Specifically recovery can no longer be driven off consideration of the
gtrid ownership alone, but must also consider bqual ownership. This naturally requires
that the bqual value actually contain node ownership information, which will require a new
encoding. On the other hand we probably need one anyhow to communicate delegation of the
bqual state space on links where we're working with 3rd party implementations and thus
constrained to the JCA api rather than one that could carry additional parameters. For
links where we do control both ends, we need additional methods to support afterCompletion
as a separate phase. BeforeCompletion is already available as a separate step on
subordinate transactions, although it may need to be even finer grained to allow for JTA
1.1 TSR sync interposition semantics to be transaction global rather than node local.
In both models the communication is entirely top down - the coordinator does not exist as
a network endpoint as in JTS, as persistent ids are not supported by the remoting
transport. This constrains recovery to use the XA recovery scan model rather than the JTS
replayCompletion one. One consequence of this is that parent nodes will require to
maintain a list of all possible subordinates and have a recovery module plugin for them,
but that's probably not an undue burden for most deployment scenarios. Another
consequence is that it's probably going to be better to build it as distributed hooks
into JBossJTA rather than a pluggable transport layer for JBossJTS. That should also offer
better performance as resource records will get inlined to the tx rather than be separate
ostore entries.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:34 a.m.
New subject: [JBoss JIRA] (JBTM-895) Expose an API that allows JTA to be controlled in a distributed manner
[
https://issues.jboss.org/browse/JBTM-895?page=com.atlassian.jira.plugin.s...
]
Tom Jenkinson updated JBTM-895:
-------------------------------
Fix Version/s: 4.15.4
(was: 4.15.x)
Expose an API that allows JTA to be controlled in a distributed
manner
----------------------------------------------------------------------
Key: JBTM-895
URL: https://issues.jboss.org/browse/JBTM-895
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Reporter: Tom Jenkinson
Assignee: Tom Jenkinson
Priority: Blocker
Fix For: 4.15.4
This feature is requested by the Remoting team.
Options are:
ClientUserTransaction requires no additional implementation work. The same hooks that
supported the earlier implementations of this can be used for the new one too.
Transaction context inflow support falls into two parts: whole transaction (gtrid)
interposition and branch only (bqual) interposition.
For whole transaction interposition, a new subordinate transaction context is created on
each node receiving an inflow. Synchronizations are handled purely locally. The JCA inflow
API can be used, albeit with semantics which IMO are not spec compliant. This model would
be relatively simple to implement on the transaction manager side, as the existing
recovery architecture will mostly still apply. IMO it's of limited utility for users
though, as resource managers will see independent transactions and not do any transaction
branch coupling. That impacts both functionality and performance.
For branch only transaction interposition, subordinate nodes maintain the inflowed gtrid
but create new branches within an allocated portion of the bqual state space. This
requires information about the allocation of bqual space to be communicated, either by
explicit parameter passing for the general case or by encoding in the Xid for the
jboss->jboss inflow case. It affords the opportunity for branch coupling in resource
managers used by more than one node in the same transaction, but leads to more complicated
recovery needs. Specifically recovery can no longer be driven off consideration of the
gtrid ownership alone, but must also consider bqual ownership. This naturally requires
that the bqual value actually contain node ownership information, which will require a new
encoding. On the other hand we probably need one anyhow to communicate delegation of the
bqual state space on links where we're working with 3rd party implementations and thus
constrained to the JCA api rather than one that could carry additional parameters. For
links where we do control both ends, we need additional methods to support afterCompletion
as a separate phase. BeforeCompletion is already available as a separate step on
subordinate transactions, although it may need to be even finer grained to allow for JTA
1.1 TSR sync interposition semantics to be transaction global rather than node local.
In both models the communication is entirely top down - the coordinator does not exist as
a network endpoint as in JTS, as persistent ids are not supported by the remoting
transport. This constrains recovery to use the XA recovery scan model rather than the JTS
replayCompletion one. One consequence of this is that parent nodes will require to
maintain a list of all possible subordinates and have a recovery module plugin for them,
but that's probably not an undue burden for most deployment scenarios. Another
consequence is that it's probably going to be better to build it as distributed hooks
into JBossJTA rather than a pluggable transport layer for JBossJTS. That should also offer
better performance as resource records will get inlined to the tx rather than be separate
ostore entries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:08 a.m.
New subject: [JBoss JIRA] (JBTM-895) Expose an API that allows JTA to be controlled in a distributed manner
[
https://issues.jboss.org/browse/JBTM-895?page=com.atlassian.jira.plugin.s...
]
Tom Jenkinson updated JBTM-895:
-------------------------------
Fix Version/s: 4.15.x
(was: 4.15.4)
Expose an API that allows JTA to be controlled in a distributed
manner
----------------------------------------------------------------------
Key: JBTM-895
URL: https://issues.jboss.org/browse/JBTM-895
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Reporter: Tom Jenkinson
Assignee: Tom Jenkinson
Priority: Blocker
Fix For: 4.15.x
This feature is requested by the Remoting team.
Options are:
ClientUserTransaction requires no additional implementation work. The same hooks that
supported the earlier implementations of this can be used for the new one too.
Transaction context inflow support falls into two parts: whole transaction (gtrid)
interposition and branch only (bqual) interposition.
For whole transaction interposition, a new subordinate transaction context is created on
each node receiving an inflow. Synchronizations are handled purely locally. The JCA inflow
API can be used, albeit with semantics which IMO are not spec compliant. This model would
be relatively simple to implement on the transaction manager side, as the existing
recovery architecture will mostly still apply. IMO it's of limited utility for users
though, as resource managers will see independent transactions and not do any transaction
branch coupling. That impacts both functionality and performance.
For branch only transaction interposition, subordinate nodes maintain the inflowed gtrid
but create new branches within an allocated portion of the bqual state space. This
requires information about the allocation of bqual space to be communicated, either by
explicit parameter passing for the general case or by encoding in the Xid for the
jboss->jboss inflow case. It affords the opportunity for branch coupling in resource
managers used by more than one node in the same transaction, but leads to more complicated
recovery needs. Specifically recovery can no longer be driven off consideration of the
gtrid ownership alone, but must also consider bqual ownership. This naturally requires
that the bqual value actually contain node ownership information, which will require a new
encoding. On the other hand we probably need one anyhow to communicate delegation of the
bqual state space on links where we're working with 3rd party implementations and thus
constrained to the JCA api rather than one that could carry additional parameters. For
links where we do control both ends, we need additional methods to support afterCompletion
as a separate phase. BeforeCompletion is already available as a separate step on
subordinate transactions, although it may need to be even finer grained to allow for JTA
1.1 TSR sync interposition semantics to be transaction global rather than node local.
In both models the communication is entirely top down - the coordinator does not exist as
a network endpoint as in JTS, as persistent ids are not supported by the remoting
transport. This constrains recovery to use the XA recovery scan model rather than the JTS
replayCompletion one. One consequence of this is that parent nodes will require to
maintain a list of all possible subordinates and have a recovery module plugin for them,
but that's probably not an undue burden for most deployment scenarios. Another
consequence is that it's probably going to be better to build it as distributed hooks
into JBossJTA rather than a pluggable transport layer for JBossJTS. That should also offer
better performance as resource records will get inlined to the tx rather than be separate
ostore entries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:12 a.m.
New subject: [JBoss JIRA] (JBTM-895) Expose an API that allows JTA to be controlled in a distributed manner
[
https://issues.jboss.org/browse/JBTM-895?page=com.atlassian.jira.plugin.s...
]
Tom Jenkinson updated JBTM-895:
-------------------------------
Description:
This feature is requested by the Remoting team.
Options are:
ClientUserTransaction requires no additional implementation work. The same hooks that
supported the earlier implementations of this can be used for the new one too.
Transaction context inflow support falls into two parts: whole transaction (gtrid)
interposition and branch only (bqual) interposition.
For whole transaction interposition, a new subordinate transaction context is created on
each node receiving an inflow. Synchronizations are handled purely locally. The JCA inflow
API can be used, albeit with semantics which IMO are not spec compliant. This model would
be relatively simple to implement on the transaction manager side, as the existing
recovery architecture will mostly still apply. IMO it's of limited utility for users
though, as resource managers will see independent transactions and not do any transaction
branch coupling. That impacts both functionality and performance.
For branch only transaction interposition, subordinate nodes maintain the inflowed gtrid
but create new branches within an allocated portion of the bqual state space. This
requires information about the allocation of bqual space to be communicated, either by
explicit parameter passing for the general case or by encoding in the Xid for the
jboss->jboss inflow case. It affords the opportunity for branch coupling in resource
managers used by more than one node in the same transaction, but leads to more complicated
recovery needs. Specifically recovery can no longer be driven off consideration of the
gtrid ownership alone, but must also consider bqual ownership. This naturally requires
that the bqual value actually contain node ownership information, which will require a new
encoding. On the other hand we probably need one anyhow to communicate delegation of the
bqual state space on links where we're working with 3rd party implementations and thus
constrained to the JCA api rather than one that could carry additional parameters. For
links where we do control both ends, we need additional methods to support afterCompletion
as a separate phase. BeforeCompletion is already available as a separate step on
subordinate transactions, although it may need to be even finer grained to allow for JTA
1.1 TSR sync interposition semantics to be transaction global rather than node local.
In both models the communication is entirely top down - the coordinator does not exist as
a network endpoint as in JTS, as persistent ids are not supported by the remoting
transport. This constrains recovery to use the XA recovery scan model rather than the JTS
replayCompletion one. One consequence of this is that parent nodes will require to
maintain a list of all possible subordinates and have a recovery module plugin for them,
but that's probably not an undue burden for most deployment scenarios. Another
consequence is that it's probably going to be better to build it as distributed hooks
into JBossJTA rather than a pluggable transport layer for JBossJTS. That should also offer
better performance as resource records will get inlined to the tx rather than be separate
ostore entries.
It is important that the transport should not be required to persist additional data about
the transaction state in order to ensure the best performance. Any state that must be
retained should be coupled to existing persistence points such as Serializable XAResources
intermediaries.
was:
This feature is requested by the Remoting team.
Options are:
ClientUserTransaction requires no additional implementation work. The same hooks that
supported the earlier implementations of this can be used for the new one too.
Transaction context inflow support falls into two parts: whole transaction (gtrid)
interposition and branch only (bqual) interposition.
For whole transaction interposition, a new subordinate transaction context is created on
each node receiving an inflow. Synchronizations are handled purely locally. The JCA inflow
API can be used, albeit with semantics which IMO are not spec compliant. This model would
be relatively simple to implement on the transaction manager side, as the existing
recovery architecture will mostly still apply. IMO it's of limited utility for users
though, as resource managers will see independent transactions and not do any transaction
branch coupling. That impacts both functionality and performance.
For branch only transaction interposition, subordinate nodes maintain the inflowed gtrid
but create new branches within an allocated portion of the bqual state space. This
requires information about the allocation of bqual space to be communicated, either by
explicit parameter passing for the general case or by encoding in the Xid for the
jboss->jboss inflow case. It affords the opportunity for branch coupling in resource
managers used by more than one node in the same transaction, but leads to more complicated
recovery needs. Specifically recovery can no longer be driven off consideration of the
gtrid ownership alone, but must also consider bqual ownership. This naturally requires
that the bqual value actually contain node ownership information, which will require a new
encoding. On the other hand we probably need one anyhow to communicate delegation of the
bqual state space on links where we're working with 3rd party implementations and thus
constrained to the JCA api rather than one that could carry additional parameters. For
links where we do control both ends, we need additional methods to support afterCompletion
as a separate phase. BeforeCompletion is already available as a separate step on
subordinate transactions, although it may need to be even finer grained to allow for JTA
1.1 TSR sync interposition semantics to be transaction global rather than node local.
In both models the communication is entirely top down - the coordinator does not exist as
a network endpoint as in JTS, as persistent ids are not supported by the remoting
transport. This constrains recovery to use the XA recovery scan model rather than the JTS
replayCompletion one. One consequence of this is that parent nodes will require to
maintain a list of all possible subordinates and have a recovery module plugin for them,
but that's probably not an undue burden for most deployment scenarios. Another
consequence is that it's probably going to be better to build it as distributed hooks
into JBossJTA rather than a pluggable transport layer for JBossJTS. That should also offer
better performance as resource records will get inlined to the tx rather than be separate
ostore entries.
Forum Reference: http://community.jboss.org/thread/171004?tstart=0 (was:
http://community.jboss.org/thread/171004?tstart=0)
Expose an API that allows JTA to be controlled in a distributed
manner
----------------------------------------------------------------------
Key: JBTM-895
URL: https://issues.jboss.org/browse/JBTM-895
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Reporter: Tom Jenkinson
Assignee: Tom Jenkinson
Priority: Blocker
Fix For: 4.15.x
This feature is requested by the Remoting team.
Options are:
ClientUserTransaction requires no additional implementation work. The same hooks that
supported the earlier implementations of this can be used for the new one too.
Transaction context inflow support falls into two parts: whole transaction (gtrid)
interposition and branch only (bqual) interposition.
For whole transaction interposition, a new subordinate transaction context is created on
each node receiving an inflow. Synchronizations are handled purely locally. The JCA inflow
API can be used, albeit with semantics which IMO are not spec compliant. This model would
be relatively simple to implement on the transaction manager side, as the existing
recovery architecture will mostly still apply. IMO it's of limited utility for users
though, as resource managers will see independent transactions and not do any transaction
branch coupling. That impacts both functionality and performance.
For branch only transaction interposition, subordinate nodes maintain the inflowed gtrid
but create new branches within an allocated portion of the bqual state space. This
requires information about the allocation of bqual space to be communicated, either by
explicit parameter passing for the general case or by encoding in the Xid for the
jboss->jboss inflow case. It affords the opportunity for branch coupling in resource
managers used by more than one node in the same transaction, but leads to more complicated
recovery needs. Specifically recovery can no longer be driven off consideration of the
gtrid ownership alone, but must also consider bqual ownership. This naturally requires
that the bqual value actually contain node ownership information, which will require a new
encoding. On the other hand we probably need one anyhow to communicate delegation of the
bqual state space on links where we're working with 3rd party implementations and thus
constrained to the JCA api rather than one that could carry additional parameters. For
links where we do control both ends, we need additional methods to support afterCompletion
as a separate phase. BeforeCompletion is already available as a separate step on
subordinate transactions, although it may need to be even finer grained to allow for JTA
1.1 TSR sync interposition semantics to be transaction global rather than node local.
In both models the communication is entirely top down - the coordinator does not exist as
a network endpoint as in JTS, as persistent ids are not supported by the remoting
transport. This constrains recovery to use the XA recovery scan model rather than the JTS
replayCompletion one. One consequence of this is that parent nodes will require to
maintain a list of all possible subordinates and have a recovery module plugin for them,
but that's probably not an undue burden for most deployment scenarios. Another
consequence is that it's probably going to be better to build it as distributed hooks
into JBossJTA rather than a pluggable transport layer for JBossJTS. That should also offer
better performance as resource records will get inlined to the tx rather than be separate
ostore entries.
It is important that the transport should not be required to persist additional data
about the transaction state in order to ensure the best performance. Any state that must
be retained should be coupled to existing persistence points such as Serializable
XAResources intermediaries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:31 a.m.
New subject: [JBoss JIRA] (JBTM-895) Expose an API that allows JTA to be controlled in a distributed manner
[
https://issues.jboss.org/browse/JBTM-895?page=com.atlassian.jira.plugin.s...
]
Tom Jenkinson updated JBTM-895:
-------------------------------
Fix Version/s: 4.16.0.Final
(was: 4.16.x)
Expose an API that allows JTA to be controlled in a distributed
manner
----------------------------------------------------------------------
Key: JBTM-895
URL: https://issues.jboss.org/browse/JBTM-895
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Reporter: Tom Jenkinson
Assignee: Tom Jenkinson
Priority: Blocker
Fix For: 4.16.0.Final
This feature is requested by the Remoting team.
Options are:
ClientUserTransaction requires no additional implementation work. The same hooks that
supported the earlier implementations of this can be used for the new one too.
Transaction context inflow support falls into two parts: whole transaction (gtrid)
interposition and branch only (bqual) interposition.
For whole transaction interposition, a new subordinate transaction context is created on
each node receiving an inflow. Synchronizations are handled purely locally. The JCA inflow
API can be used, albeit with semantics which IMO are not spec compliant. This model would
be relatively simple to implement on the transaction manager side, as the existing
recovery architecture will mostly still apply. IMO it's of limited utility for users
though, as resource managers will see independent transactions and not do any transaction
branch coupling. That impacts both functionality and performance.
For branch only transaction interposition, subordinate nodes maintain the inflowed gtrid
but create new branches within an allocated portion of the bqual state space. This
requires information about the allocation of bqual space to be communicated, either by
explicit parameter passing for the general case or by encoding in the Xid for the
jboss->jboss inflow case. It affords the opportunity for branch coupling in resource
managers used by more than one node in the same transaction, but leads to more complicated
recovery needs. Specifically recovery can no longer be driven off consideration of the
gtrid ownership alone, but must also consider bqual ownership. This naturally requires
that the bqual value actually contain node ownership information, which will require a new
encoding. On the other hand we probably need one anyhow to communicate delegation of the
bqual state space on links where we're working with 3rd party implementations and thus
constrained to the JCA api rather than one that could carry additional parameters. For
links where we do control both ends, we need additional methods to support afterCompletion
as a separate phase. BeforeCompletion is already available as a separate step on
subordinate transactions, although it may need to be even finer grained to allow for JTA
1.1 TSR sync interposition semantics to be transaction global rather than node local.
In both models the communication is entirely top down - the coordinator does not exist as
a network endpoint as in JTS, as persistent ids are not supported by the remoting
transport. This constrains recovery to use the XA recovery scan model rather than the JTS
replayCompletion one. One consequence of this is that parent nodes will require to
maintain a list of all possible subordinates and have a recovery module plugin for them,
but that's probably not an undue burden for most deployment scenarios. Another
consequence is that it's probably going to be better to build it as distributed hooks
into JBossJTA rather than a pluggable transport layer for JBossJTS. That should also offer
better performance as resource records will get inlined to the tx rather than be separate
ostore entries.
It is important that the transport should not be required to persist additional data
about the transaction state in order to ensure the best performance. Any state that must
be retained should be coupled to existing persistence points such as Serializable
XAResources intermediaries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:08 p.m.
New subject: [JBoss JIRA] (JBTM-895) Expose an API that allows JTA to be controlled in a distributed manner
[
https://issues.jboss.org/browse/JBTM-895?page=com.atlassian.jira.plugin.s...
]
Tom Jenkinson updated JBTM-895:
-------------------------------
Component/s: JCA
JTA
Forum Reference: http://community.jboss.org/thread/171004?tstart=0 (was:
http://community.jboss.org/thread/171004?tstart=0)
Expose an API that allows JTA to be controlled in a distributed
manner
----------------------------------------------------------------------
Key: JBTM-895
URL: https://issues.jboss.org/browse/JBTM-895
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JCA, JTA
Reporter: Tom Jenkinson
Assignee: Tom Jenkinson
Priority: Blocker
Fix For: 4.16.0.Final
This feature is requested by the Remoting team.
Options are:
ClientUserTransaction requires no additional implementation work. The same hooks that
supported the earlier implementations of this can be used for the new one too.
Transaction context inflow support falls into two parts: whole transaction (gtrid)
interposition and branch only (bqual) interposition.
For whole transaction interposition, a new subordinate transaction context is created on
each node receiving an inflow. Synchronizations are handled purely locally. The JCA inflow
API can be used, albeit with semantics which IMO are not spec compliant. This model would
be relatively simple to implement on the transaction manager side, as the existing
recovery architecture will mostly still apply. IMO it's of limited utility for users
though, as resource managers will see independent transactions and not do any transaction
branch coupling. That impacts both functionality and performance.
For branch only transaction interposition, subordinate nodes maintain the inflowed gtrid
but create new branches within an allocated portion of the bqual state space. This
requires information about the allocation of bqual space to be communicated, either by
explicit parameter passing for the general case or by encoding in the Xid for the
jboss->jboss inflow case. It affords the opportunity for branch coupling in resource
managers used by more than one node in the same transaction, but leads to more complicated
recovery needs. Specifically recovery can no longer be driven off consideration of the
gtrid ownership alone, but must also consider bqual ownership. This naturally requires
that the bqual value actually contain node ownership information, which will require a new
encoding. On the other hand we probably need one anyhow to communicate delegation of the
bqual state space on links where we're working with 3rd party implementations and thus
constrained to the JCA api rather than one that could carry additional parameters. For
links where we do control both ends, we need additional methods to support afterCompletion
as a separate phase. BeforeCompletion is already available as a separate step on
subordinate transactions, although it may need to be even finer grained to allow for JTA
1.1 TSR sync interposition semantics to be transaction global rather than node local.
In both models the communication is entirely top down - the coordinator does not exist as
a network endpoint as in JTS, as persistent ids are not supported by the remoting
transport. This constrains recovery to use the XA recovery scan model rather than the JTS
replayCompletion one. One consequence of this is that parent nodes will require to
maintain a list of all possible subordinates and have a recovery module plugin for them,
but that's probably not an undue burden for most deployment scenarios. Another
consequence is that it's probably going to be better to build it as distributed hooks
into JBossJTA rather than a pluggable transport layer for JBossJTS. That should also offer
better performance as resource records will get inlined to the tx rather than be separate
ostore entries.
It is important that the transport should not be required to persist additional data
about the transaction state in order to ensure the best performance. Any state that must
be retained should be coupled to existing persistence points such as Serializable
XAResources intermediaries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:39 a.m.
New subject: [JBoss JIRA] (JBTM-895) Expose an API that allows JTA to be controlled in a distributed manner
[
https://issues.jboss.org/browse/JBTM-895?page=com.atlassian.jira.plugin.s...
]
Tom Jenkinson resolved JBTM-895.
--------------------------------
Resolution: Done
Done
Expose an API that allows JTA to be controlled in a distributed
manner
----------------------------------------------------------------------
Key: JBTM-895
URL: https://issues.jboss.org/browse/JBTM-895
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JCA, JTA
Reporter: Tom Jenkinson
Assignee: Tom Jenkinson
Priority: Blocker
Fix For: 4.16.0.Final
This feature is requested by the Remoting team.
Options are:
ClientUserTransaction requires no additional implementation work. The same hooks that
supported the earlier implementations of this can be used for the new one too.
Transaction context inflow support falls into two parts: whole transaction (gtrid)
interposition and branch only (bqual) interposition.
For whole transaction interposition, a new subordinate transaction context is created on
each node receiving an inflow. Synchronizations are handled purely locally. The JCA inflow
API can be used, albeit with semantics which IMO are not spec compliant. This model would
be relatively simple to implement on the transaction manager side, as the existing
recovery architecture will mostly still apply. IMO it's of limited utility for users
though, as resource managers will see independent transactions and not do any transaction
branch coupling. That impacts both functionality and performance.
For branch only transaction interposition, subordinate nodes maintain the inflowed gtrid
but create new branches within an allocated portion of the bqual state space. This
requires information about the allocation of bqual space to be communicated, either by
explicit parameter passing for the general case or by encoding in the Xid for the
jboss->jboss inflow case. It affords the opportunity for branch coupling in resource
managers used by more than one node in the same transaction, but leads to more complicated
recovery needs. Specifically recovery can no longer be driven off consideration of the
gtrid ownership alone, but must also consider bqual ownership. This naturally requires
that the bqual value actually contain node ownership information, which will require a new
encoding. On the other hand we probably need one anyhow to communicate delegation of the
bqual state space on links where we're working with 3rd party implementations and thus
constrained to the JCA api rather than one that could carry additional parameters. For
links where we do control both ends, we need additional methods to support afterCompletion
as a separate phase. BeforeCompletion is already available as a separate step on
subordinate transactions, although it may need to be even finer grained to allow for JTA
1.1 TSR sync interposition semantics to be transaction global rather than node local.
In both models the communication is entirely top down - the coordinator does not exist as
a network endpoint as in JTS, as persistent ids are not supported by the remoting
transport. This constrains recovery to use the XA recovery scan model rather than the JTS
replayCompletion one. One consequence of this is that parent nodes will require to
maintain a list of all possible subordinates and have a recovery module plugin for them,
but that's probably not an undue burden for most deployment scenarios. Another
consequence is that it's probably going to be better to build it as distributed hooks
into JBossJTA rather than a pluggable transport layer for JBossJTS. That should also offer
better performance as resource records will get inlined to the tx rather than be separate
ostore entries.
It is important that the transport should not be required to persist additional data
about the transaction state in order to ensure the best performance. Any state that must
be retained should be coupled to existing persistence points such as Serializable
XAResources intermediaries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:42 a.m.
New subject: [JBoss JIRA] (JBTM-895) Expose an API that allows JTA to be controlled in a distributed manner
[
https://issues.jboss.org/browse/JBTM-895?page=com.atlassian.jira.plugin.s...
]
Jason Greene commented on JBTM-895:
-----------------------------------
Awesome you guys rock!
Expose an API that allows JTA to be controlled in a distributed
manner
----------------------------------------------------------------------
Key: JBTM-895
URL: https://issues.jboss.org/browse/JBTM-895
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JCA, JTA
Reporter: Tom Jenkinson
Assignee: Tom Jenkinson
Priority: Blocker
Fix For: 4.16.0.Final
This feature is requested by the Remoting team.
Options are:
ClientUserTransaction requires no additional implementation work. The same hooks that
supported the earlier implementations of this can be used for the new one too.
Transaction context inflow support falls into two parts: whole transaction (gtrid)
interposition and branch only (bqual) interposition.
For whole transaction interposition, a new subordinate transaction context is created on
each node receiving an inflow. Synchronizations are handled purely locally. The JCA inflow
API can be used, albeit with semantics which IMO are not spec compliant. This model would
be relatively simple to implement on the transaction manager side, as the existing
recovery architecture will mostly still apply. IMO it's of limited utility for users
though, as resource managers will see independent transactions and not do any transaction
branch coupling. That impacts both functionality and performance.
For branch only transaction interposition, subordinate nodes maintain the inflowed gtrid
but create new branches within an allocated portion of the bqual state space. This
requires information about the allocation of bqual space to be communicated, either by
explicit parameter passing for the general case or by encoding in the Xid for the
jboss->jboss inflow case. It affords the opportunity for branch coupling in resource
managers used by more than one node in the same transaction, but leads to more complicated
recovery needs. Specifically recovery can no longer be driven off consideration of the
gtrid ownership alone, but must also consider bqual ownership. This naturally requires
that the bqual value actually contain node ownership information, which will require a new
encoding. On the other hand we probably need one anyhow to communicate delegation of the
bqual state space on links where we're working with 3rd party implementations and thus
constrained to the JCA api rather than one that could carry additional parameters. For
links where we do control both ends, we need additional methods to support afterCompletion
as a separate phase. BeforeCompletion is already available as a separate step on
subordinate transactions, although it may need to be even finer grained to allow for JTA
1.1 TSR sync interposition semantics to be transaction global rather than node local.
In both models the communication is entirely top down - the coordinator does not exist as
a network endpoint as in JTS, as persistent ids are not supported by the remoting
transport. This constrains recovery to use the XA recovery scan model rather than the JTS
replayCompletion one. One consequence of this is that parent nodes will require to
maintain a list of all possible subordinates and have a recovery module plugin for them,
but that's probably not an undue burden for most deployment scenarios. Another
consequence is that it's probably going to be better to build it as distributed hooks
into JBossJTA rather than a pluggable transport layer for JBossJTS. That should also offer
better performance as resource records will get inlined to the tx rather than be separate
ostore entries.
It is important that the transport should not be required to persist additional data
about the transaction state in order to ensure the best performance. Any state that must
be retained should be coupled to existing persistence points such as Serializable
XAResources intermediaries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4734
days inactive
4818
days old
jbossts-issues@lists.jboss.org
8 comments
4 participants
participants (4)
-
Jason Greene (Commented) (JIRA) -
Tom Jenkinson (JIRA)
-
Tom Jenkinson (Resolved) (JIRA)
-
Tom Jenkinson (Updated) (JIRA)