Fake XA support?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Fake XA support?

Peter Giles-2
I'm anticipating that this may be a controversial question, but are there any plans or possibilities of adding non-XA support?  What I mean by that is something similar to what XAPool provided for non-XA datasources, which (more or less) allowed you to synchronize your commit across multiple data sources using JTA, but didn't provide the iron clad guarantees that XA does around failures.  Atomikos supports something similar : http://www.atomikos.com/Documentation/NonXaDataSource  

Having non-XA as an option allows for greater flexibility (though at a definite cost) for clients to work with db platforms that lack XA drivers, or have lousy XA drivers.  I won't name names, but one wildly popular open source db comes to mind.  It also allows projects that are using XAPool (perhaps there aren't that many anymore) or Atomikos in the above fashion a clearer migration path to Bitronix.  The latter point is where I'm coming at this from BTW.

Your thoughts?

Thanks!
Peter

P.S. I did search Nabble for previous posts on this topic and didn't find anything -- apologies if my search-fu was inadequate.

Reply | Threaded
Open this post in threaded view
|

Re: Fake XA support?

Peter Giles-2
BTW, I meant to emphasize "more than one non-XA datasource" to make clear that LRC isn't sufficient.  Also, Since posting the previous question, I came across this: http://jira.codehaus.org/browse/BTM-97

Would I be correct in interpreting that the second enhancement mentioned therein will allow for functionality similar to what XAPool and the Atomikox NonXaDataSource offer for multiple non-XA datasources, or is this in fact somehow less "production ready" than those options?  Perhaps this is a difficult/unfair question to ask? :-)

Thank you again,
Peter

On Wed, Mar 2, 2011 at 4:31 PM, Peter Giles wrote:
I'm anticipating that this may be a controversial question, but are there any plans or possibilities of adding non-XA support?  What I mean by that is something similar to what XAPool provided for non-XA datasources, which (more or less) allowed you to synchronize your commit across multiple data sources using JTA, but didn't provide the iron clad guarantees that XA does around failures.  Atomikos supports something similar : http://www.atomikos.com/Documentation/NonXaDataSource  

Having non-XA as an option allows for greater flexibility (though at a definite cost) for clients to work with db platforms that lack XA drivers, or have lousy XA drivers.  I won't name names, but one wildly popular open source db comes to mind.  It also allows projects that are using XAPool (perhaps there aren't that many anymore) or Atomikos in the above fashion a clearer migration path to Bitronix.  The latter point is where I'm coming at this from BTW.

Your thoughts?

Thanks!
Peter

P.S. I did search Nabble for previous posts on this topic and didn't find anything -- apologies if my search-fu was inadequate.




--
Peter Giles  |  Kuali Rice dev team  |  UW Information Management
Reply | Threaded
Open this post in threaded view
|

Re: Re: Fake XA support?

Ludovic Orban-2
Hi Peter,

As soon as you start adding non-xa resources in a global transaction, you increase the risk of having non-atomic outcomes. With a single resource, the LRC algorithm guarantees that only a transaction manager crash can jeopardize your transaction's atomicity. With more than one, other facts can make the transaction end up non-atomic. The risks can be mitigated depending on the transaction manager's implementation but they can never be fully eliminated.

BTM always allowed for LRC as I believe this provides a reasonable balance between safety and usability but some users asked for more, mostly for development purpose so I ended up integrating the patch proposed in BTM-97. With the 2.1.1 release you'll be able to configure and enlist as many LRC resources as you want in a transaction if you set the allowMultipleLrc configuration setting to true.

To make this mechanism as safe as the single LRC one, you must guarantee that commit can never fail on any resource. Remember this is what it takes for BTM, other JTA implementations could have different requirements.
I wouldn't feel confident with such configuration on a production system so I'm not recommending it, no matter what transaction manager you're using. I'm afraid to say your only safe option is to use a DB with a working XA support even if I know it's easily said but hardly possible most of the time.

Summary: it's possible but it is my opinion that such system is not production ready, JOTM / XAPool, Atomikos and all the other JTA implementations out there are no exception.

Ludovic

2011/3/3 Peter Giles <[hidden email]>
BTW, I meant to emphasize "more than one non-XA datasource" to make clear that LRC isn't sufficient.  Also, Since posting the previous question, I came across this: http://jira.codehaus.org/browse/BTM-97

Would I be correct in interpreting that the second enhancement mentioned therein will allow for functionality similar to what XAPool and the Atomikox NonXaDataSource offer for multiple non-XA datasources, or is this in fact somehow less "production ready" than those options?  Perhaps this is a difficult/unfair question to ask? :-)

Thank you again,
Peter

On Wed, Mar 2, 2011 at 4:31 PM, Peter Giles wrote:
I'm anticipating that this may be a controversial question, but are there any plans or possibilities of adding non-XA support?  What I mean by that is something similar to what XAPool provided for non-XA datasources, which (more or less) allowed you to synchronize your commit across multiple data sources using JTA, but didn't provide the iron clad guarantees that XA does around failures.  Atomikos supports something similar : http://www.atomikos.com/Documentation/NonXaDataSource  

Having non-XA as an option allows for greater flexibility (though at a definite cost) for clients to work with db platforms that lack XA drivers, or have lousy XA drivers.  I won't name names, but one wildly popular open source db comes to mind.  It also allows projects that are using XAPool (perhaps there aren't that many anymore) or Atomikos in the above fashion a clearer migration path to Bitronix.  The latter point is where I'm coming at this from BTW.

Your thoughts?

Thanks!
Peter

P.S. I did search Nabble for previous posts on this topic and didn't find anything -- apologies if my search-fu was inadequate.




--
Peter Giles  |  Kuali Rice dev team  |  UW Information Management

Reply | Threaded
Open this post in threaded view
|

Re: Re: Fake XA support?

Peter Giles-2
Hi Ludovic, 

Your points are well taken.  Thanks for the thoughtful response.

Peter

On Thu, Mar 3, 2011 at 1:31 AM, Ludovic Orban wrote:
Hi Peter,

As soon as you start adding non-xa resources in a global transaction, you increase the risk of having non-atomic outcomes. With a single resource, the LRC algorithm guarantees that only a transaction manager crash can jeopardize your transaction's atomicity. With more than one, other facts can make the transaction end up non-atomic. The risks can be mitigated depending on the transaction manager's implementation but they can never be fully eliminated.

BTM always allowed for LRC as I believe this provides a reasonable balance between safety and usability but some users asked for more, mostly for development purpose so I ended up integrating the patch proposed in BTM-97. With the 2.1.1 release you'll be able to configure and enlist as many LRC resources as you want in a transaction if you set the allowMultipleLrc configuration setting to true.

To make this mechanism as safe as the single LRC one, you must guarantee that commit can never fail on any resource. Remember this is what it takes for BTM, other JTA implementations could have different requirements.
I wouldn't feel confident with such configuration on a production system so I'm not recommending it, no matter what transaction manager you're using. I'm afraid to say your only safe option is to use a DB with a working XA support even if I know it's easily said but hardly possible most of the time.

Summary: it's possible but it is my opinion that such system is not production ready, JOTM / XAPool, Atomikos and all the other JTA implementations out there are no exception.

Ludovic

2011/3/3 Peter Giles

BTW, I meant to emphasize "more than one non-XA datasource" to make clear that LRC isn't sufficient.  Also, Since posting the previous question, I came across this: http://jira.codehaus.org/browse/BTM-97

Would I be correct in interpreting that the second enhancement mentioned therein will allow for functionality similar to what XAPool and the Atomikox NonXaDataSource offer for multiple non-XA datasources, or is this in fact somehow less "production ready" than those options?  Perhaps this is a difficult/unfair question to ask? :-)

Thank you again,
Peter

On Wed, Mar 2, 2011 at 4:31 PM, Peter Giles wrote:
I'm anticipating that this may be a controversial question, but are there any plans or possibilities of adding non-XA support?  What I mean by that is something similar to what XAPool provided for non-XA datasources, which (more or less) allowed you to synchronize your commit across multiple data sources using JTA, but didn't provide the iron clad guarantees that XA does around failures.  Atomikos supports something similar : http://www.atomikos.com/Documentation/NonXaDataSource  

Having non-XA as an option allows for greater flexibility (though at a definite cost) for clients to work with db platforms that lack XA drivers, or have lousy XA drivers.  I won't name names, but one wildly popular open source db comes to mind.  It also allows projects that are using XAPool (perhaps there aren't that many anymore) or Atomikos in the above fashion a clearer migration path to Bitronix.  The latter point is where I'm coming at this from BTW.

Your thoughts?

Thanks!
Peter

P.S. I did search Nabble for previous posts on this topic and didn't find anything -- apologies if my search-fu was inadequate.




--
Peter Giles  |  Kuali Rice dev team  |  UW Information Management




--
Peter Giles  |  Kuali Rice dev team  |  UW Information Management