1 2 Previous Next 25 Replies Latest reply on Nov 28, 2006 12:37 PM by marklittle

    JBossTS/JBossJCA XA/Local transactions

    weston.price

      JBossTS does not support he use of multiple resources with LocalTransactions. As a result, I can see this causing issue with both previous applications attempting to migrate to JBoss5 as well as new development efforts that do not want to use XA (for whatever reason) or cannot afforce XA for whatever reason.

      Since this functionality exists in JBossTM, I believe this warrants some discussion.

        • 1. Re: JBossTS/JBossJCA XA/Local transactions
          marklittle

          Why do you believe you need this support? JBossTS, like other commercial-grade/enterprise transaction systems, supports the TWO-PHASE COMMIT protocol. This means participants need to understand the prepare/commit/rollback messages they will get from the coordinator.

          Now obviously not ever participant in existance is 2PC-aware. In that case, as with other products such as Tux and CICS, we support LRCO. This allows a single 1-phase aware participant to be enlisted with a two-phase transaction as long as it is handled correctly within the protocol. If it isn't, or if you try to add more than one 1-phase aware participant, then you will potentially end up with non-atomic behaviour. Believe it or not, but that's not a good idea. Heuristic outcomes are bad enough, but at least with them you have durably recorded the results and can attempt some form or resolution, even if manually.

          There's a really good book on the subject:

          http://www.amazon.com/Java-Transaction-Processing-Implementation-Professional/dp/013035290X/sr=8-1/qid=1164621306/ref=sr_1_1/102-7032136-5452124?ie=UTF8&s=books

          So rather than rush into supporting something like this, I'd prefer to see a discussion about why it is needed in the first place. If there's a real need then we can consider it, but definitely a case of caveat emptor!

          • 2. Re: JBossTS/JBossJCA XA/Local transactions
            kconner

             

            There's a really good book on the subject:

            I'm sure there are better ones out there ;-)

            Kev


            • 3. Re: JBossTS/JBossJCA XA/Local transactions
              rupertlssmith

              Thank goodness for JBossTS. It is the missing piece in turning JBoss into a 'real' application server.

              I suggested on the other thread, that if it _really_ needs to support the broken XA implementation of JBossTM, purely for backward compatibility convenience, maybe a config switch should be added to turn it on? With suitable warnings issued at start up, or when enlisting multiple local tx resources?

              • 4. Re: JBossTS/JBossJCA XA/Local transactions
                weston.price

                 


                Why do you believe you need this support?


                I am not saying we 'should' support it. I was trying to point out that JBossTM supported this type of scenario Without it, migration efforts to JBoss5 and new development could become costly.

                Consider a few simple scenarios:

                1) I have 2 databases both Postgres. Using JBossTS, I cannot use them simultaneously.

                2) My company has DB2 and we would like to use the thin (db2jcc) driver. This driver does not support native XA, but we still want to us it and use multiple LocalTX datasources in our EJBs.

                3) I have WebSphereMQ, my company cannot afford the non-transactional client I still want to use the product. I have to be very careful about what scenarios I can use it withing JBoss5, where before I did not.

                4) I have n+ applications written on JBoss4 that use 2 or more LocalTx resources. My DB provider does not support XA, or we do not want to pay for XA capability. What do I do?


                Now obviously not ever participant in existance is 2PC-aware. In that case, as with other products such as Tux and CICS, we support LRCO.


                Sigh...yes I know this, but thanks for the good news!. Lord knows I would never have cause to know something like this when working on JCA. Thanks for the clarification.

                Let me reiterate, I am not advocating this type of configuration. I am simple stating that previous versions of JBoss supported this and anyone attempting to migrate their applications will most likely run into this issue. Theory and 'best practices' are great, but in the long run, when rubber hits the road these types of scenarios can present real problems in terms of backwards compatibilty.


                There's a really good book on the subject:


                Goddamnit!

                Why does everyone at JBoss feel the need to write up a pontificating book report when the subject of transactions comes up? What's more annoying is that you damn good and well that I own, and have read, this sparkling tome of wisom. In fact we have discussed it! So, I am not sure what you were driving at by posting that in here other than as a shameless plug.

                Maybe if I ask nice enough I can get your autograph too! God knows I would love to have a signed copy of this masterpiece ;-)




                • 5. Re: JBossTS/JBossJCA XA/Local transactions
                  marklittle

                   

                  "weston.price@jboss.com" wrote:

                  Why do you believe you need this support?


                  I am not saying we 'should' support it. I was trying to point out that JBossTM supported this type of scenario Without it, migration efforts to JBoss5 and new development could become costly.


                  It could, but to follow this reasoning to its logical conclusion, we'd need to provide backward compatibility in other areas, e.g., disabling recovery by default, stopping distributed transactions, no Web Services support, poor documentation? Not a good argument IMO ;-)


                  Consider a few simple scenarios:

                  1) I have 2 databases both Postgres. Using JBossTS, I cannot use them simultaneously.


                  You can if they support 2PC. If they don't, then there is no point in putting them both in a single 2PC transaction anyway. JBossTM may have "supported" this (or allowed it), but it wasn't doing users any favours. What semantics do you think it supported as a result? Not coordinated outcome for sure.


                  2) My company has DB2 and we would like to use the thin (db2jcc) driver. This driver does not support native XA, but we still want to us it and use multiple LocalTX datasources in our EJBs.


                  Same as above. I think you're ignoring one of the reason for using transactions: guaranteed consistent outcome across participants. Sure, JBossTM let you put N one-phase aware participants into a transaction, but it didn't/couldn't give you any guarantees in the presence of failures. In that case, there really is little point in doing the work within a transaction: you get the overhead of 2PC without any of the benefits.

                  If customers think that they are getting benefits from this kind of scenario then I think they are being ill advised. This is an education issue rather than a technical debate.


                  3) I have WebSphereMQ, my company cannot afford the non-transactional client I still want to use the product. I have to be very careful about what scenarios I can use it withing JBoss5, where before I did not.


                  No. Before we simply ignored the fact that failures would result in non-atomic outcomes!


                  4) I have n+ applications written on JBoss4 that use 2 or more LocalTx resources. My DB provider does not support XA, or we do not want to pay for XA capability. What do I do?


                  You understand what the limitations of that scenario are. If you still want to call commit or rollback on multiple resources/JDBC 1.0 drivers, then write a wrapper class that you register them with rather than mis-using the transaction layer, and add commit/rollback methods to that. Call it a Unit of Work (which is pretty much what IBM did back in the 70's). Or, more likely, point them at the WS-BA model, which is supported outside of Web Services at the native level and uses a forward compensation model. This works on the assumption that failures don't happen often and it's easier to roll forward during recovery. The old JBossTM implementation worked in a similar way ;-)



                  Now obviously not ever participant in existance is 2PC-aware. In that case, as with other products such as Tux and CICS, we support LRCO.


                  Sigh...yes I know this, but thanks for the good news!. Lord knows I would never have cause to know something like this when working on JCA. Thanks for the clarification.


                  I did say it was obvious. However, since you appear(ed) to be advocating something that was also obviously a very bad idea, I thought it best not to leave anything to chance!

                  Just because something CAN BE DONE, doesn't mean it SHOULD BE DONE. Fine, we were able to support this approach in JBossTM, but that doesn't make it right. If there are customers out there who really do need this capability and understand that this is a broken approach, then we can look at some kind of support, but it won't be a transaction, it won't be JTA compliant, or JTS compliant!


                  Let me reiterate, I am not advocating this type of configuration. I am simple stating that previous versions of JBoss supported this and anyone attempting to migrate their applications will most likely run into this issue.


                  Anyone attempting to migrate an application will most likely run into the recovery aspect first ;-)


                  Theory and 'best practices' are great, but in the long run, when rubber hits the road these types of scenarios can present real problems in terms of backwards compatibilty.


                  Let's wait and see. But this isn't related to "theory". It's a core requirement of any ACID transaction system to guarantee consistency in the presence of failures or concurrent access to data. Repeat after me: A stands for ATOMIC ;-)



                  There's a really good book on the subject:


                  Goddamnit!

                  Why does everyone at JBoss feel the need to write up a pontificating book report when the subject of transactions comes up? What's more annoying is that you damn good and well that I own, and have read, this sparkling tome of wisom. In fact we have discussed it! So, I am not sure what you were driving at by posting that in here other than as a shameless plug.


                  It's Christmas. It would make a very good present ;-) I've a wife and two kids to support, plus 3 cats. GO AND BUY IT AGAIN. You know if makes sense ;-)


                  Maybe if I ask nice enough I can get your autograph too! God knows I would love to have a signed copy of this masterpiece ;-)


                  Autographs are $50 a piece ;-)

                  • 6. Re: JBossTS/JBossJCA XA/Local transactions
                    weston.price

                     


                    It could, but to follow this reasoning to its logical conclusion, we'd need to provide backward compatibility in other areas, e.g., disabling recovery by default, stopping distributed transactions, no Web Services support, poor documentation? Not a good argument IMO ;-)


                    Red Herring. Nice try.


                    You can if they support 2PC. If they don't, then there is no point in putting them both in a single 2PC transaction anyway.


                    This is the crux of the issue. Technically, IMO this scnerio should never involve the use of an external TM to begin with. Rather, it should be handled locally per ResourceManager. This would be something I think we should consider looking at as a'solution'.


                    Sure, JBossTM let you put N one-phase aware participants into a transaction, but it didn't/couldn't give you any guarantees in the presence of failures. In that case, there really is little point in doing the work within a transaction: you get the overhead of 2PC without any of the benefits.


                    Yes! Please refer to my previous comment.


                    If customers think that they are getting benefits from this kind of scenario then I think they are being ill advised. This is an education issue rather than a technical debate.


                    I am not sure 'benefits' is the right term. What customers typically *DO NOT* want is for stuff that worked in one version to suddenly stop working in the next.


                    I did say it was obvious. However, since you appear(ed) to be advocating something that was also obviously a very bad idea, I thought it best not to leave anything to chance!


                    Sigh...As I *thought* I clearly stated, I am not advocating this solution.

                    My quotes:



                    'I am not saying we 'should' support it...'

                    and

                    'Let me reiterate, I am not advocating this type of configuration.'

                    finally

                    Since this functionality exists in JBossTM, I believe this warrants some discussion.



                    Again, I am not advocating so much as I am raising it as a red flag moving forward.


                    Let's wait and see. But this isn't related to "theory". It's a core requirement of any ACID transaction system to guarantee consistency in the presence of failures or concurrent access to data. Repeat after me: A stands for ATOMIC ;-)


                    I can think of another word *A* stands for right about now ;-)


                    It would make a very good present ;-)


                    It's a crapshoot.


                    I've a wife and two kids to support, plus 3 cats.


                    Thanks for sharing! I always love hearing about the personal lives of celebrities.


                    GO AND BUY IT AGAIN.


                    Once the demmand for the book dies down, I will see if I can *sneak* in and grab a copy.


                    You know if makes sense ;-)


                    HAPPY CHRISTMAS!!!!!


                    • 7. Re: JBossTS/JBossJCA XA/Local transactions
                      marklittle

                       

                      "weston.price@jboss.com" wrote:

                      It could, but to follow this reasoning to its logical conclusion, we'd need to provide backward compatibility in other areas, e.g., disabling recovery by default, stopping distributed transactions, no Web Services support, poor documentation? Not a good argument IMO ;-)


                      Red Herring. Nice try.


                      You can if they support 2PC. If they don't, then there is no point in putting them both in a single 2PC transaction anyway.


                      This is the crux of the issue. Technically, IMO this scnerio should never involve the use of an external TM to begin with. Rather, it should be handled locally per ResourceManager. This would be something I think we should consider looking at as a'solution'.


                      Hey, who said we'd not agree on something ;)?



                      Sure, JBossTM let you put N one-phase aware participants into a transaction, but it didn't/couldn't give you any guarantees in the presence of failures. In that case, there really is little point in doing the work within a transaction: you get the overhead of 2PC without any of the benefits.


                      Yes! Please refer to my previous comment.


                      If customers think that they are getting benefits from this kind of scenario then I think they are being ill advised. This is an education issue rather than a technical debate.


                      I am not sure 'benefits' is the right term. What customers typically *DO NOT* want is for stuff that worked in one version to suddenly stop working in the next.


                      That depends how you explain it to them. Remember: A is for Atomic ;-)



                      I did say it was obvious. However, since you appear(ed) to be advocating something that was also obviously a very bad idea, I thought it best not to leave anything to chance!


                      Sigh...As I *thought* I clearly stated, I am not advocating this solution.

                      My quotes:



                      'I am not saying we 'should' support it...'

                      and

                      'Let me reiterate, I am not advocating this type of configuration.'

                      finally

                      Since this functionality exists in JBossTM, I believe this warrants some discussion.



                      Again, I am not advocating so much as I am raising it as a red flag moving forward.


                      Let's wait and see. But this isn't related to "theory". It's a core requirement of any ACID transaction system to guarantee consistency in the presence of failures or concurrent access to data. Repeat after me: A stands for ATOMIC ;-)


                      I can think of another word *A* stands for right about now ;-)


                      Yeah, me too and I haven't even got to C yet ;-)

                      • 8. Re: JBossTS/JBossJCA XA/Local transactions
                        bill.burke

                        +1 for Weston.

                        Mark, why are you being so religious and academic. Weston states all valid cases for the feature. Transactions/unit of work is still extremely useful even without 2pc.

                        • 9. Re: JBossTS/JBossJCA XA/Local transactions
                          marklittle

                           

                          "bill.burke@jboss.com" wrote:
                          +1 for Weston.

                          Mark, why are you being so religious and academic. Weston states all valid cases for the feature. Transactions/unit of work is still extremely useful even without 2pc.


                          Bill, this is not academic. Multiple one-phase resources in a two-phase transaction does not give you the consistency and atomicity guarantees. When you don't support recovery then it really doesn't make a difference. But when you do, it is wrong to support this and give the impression that this is a valid approach. This is not a transaction (where the definition of transaction is JTA, JTS/OTS, XA, WS-T ACID transaction). If we want to support this, then we should be doing so through some other interface, which makes it clear that the failure and recovery semantics are different.

                          • 10. Re: JBossTS/JBossJCA XA/Local transactions
                            bill.burke

                             

                            "mark.little@jboss.com" wrote:
                            "bill.burke@jboss.com" wrote:
                            +1 for Weston.

                            Mark, why are you being so religious and academic. Weston states all valid cases for the feature. Transactions/unit of work is still extremely useful even without 2pc.


                            Bill, this is not academic. Multiple one-phase resources in a two-phase transaction does not give you the consistency and atomicity guarantees. When you don't support recovery then it really doesn't make a difference. But when you do, it is wrong to support this and give the impression that this is a valid approach. This is not a transaction (where the definition of transaction is JTA, JTS/OTS, XA, WS-T ACID transaction). If we want to support this, then we should be doing so through some other interface, which makes it clear that the failure and recovery semantics are different.


                            Listen, you don't have to spew shit I already know...I agree with you, but, as you see from Weston's post, it is not always possible to have an XA enabled resource. Things just don't fit into nice little boxes all the time and sometimes developers have to break the rules.

                            We used to spew out a warning message when a non-xa resource was being used in a two-phase transaction (not sure if we still do).

                            • 11. Re: JBossTS/JBossJCA XA/Local transactions
                              bill.burke

                              Furthermore, it is completely idiotic and gay to develop a new and different interface other than JTA if I want to use two non-XA enabled resources in the same unit of work. JTA is a great abstraction and has very tight integration with things like EJB to make your life tons easier. BTW, you're the same guy who tried to argue with me that JTA is useless when you have only one resource in your transaction.

                              Anyways, there is absolutely nothing wrong with using multiple non-XA resources in same TX if a) you can't make them all XA and/or b) more importantly, you are aware of the consequences. Forcing users ,for the sake of purity, to refactor their applications when they are aware the problem exists is just plain pompus.

                              • 12. Re: JBossTS/JBossJCA XA/Local transactions
                                marklittle

                                 

                                "bill.burke@jboss.com" wrote:
                                "mark.little@jboss.com" wrote:
                                "bill.burke@jboss.com" wrote:
                                +1 for Weston.

                                Mark, why are you being so religious and academic. Weston states all valid cases for the feature. Transactions/unit of work is still extremely useful even without 2pc.


                                Bill, this is not academic. Multiple one-phase resources in a two-phase transaction does not give you the consistency and atomicity guarantees. When you don't support recovery then it really doesn't make a difference. But when you do, it is wrong to support this and give the impression that this is a valid approach. This is not a transaction (where the definition of transaction is JTA, JTS/OTS, XA, WS-T ACID transaction). If we want to support this, then we should be doing so through some other interface, which makes it clear that the failure and recovery semantics are different.


                                Listen, you don't have to spew shit I already know...



                                And we should stop spewing shit like 'transactions without recovery are great and useful' when they're not. They are dangerous if people don't understand the full implications of what's not happening for them.


                                I agree with you, but, as you see from Weston's post, it is not always possible to have an XA enabled resource. Things just don't fit into nice little boxes all the time and sometimes developers have to break the rules.


                                Yeah, but sometimes if they are told what the implications are then they'll find a better route.


                                We used to spew out a warning message when a non-xa resource was being used in a two-phase transaction (not sure if we still do).


                                JBossTM does. JBossTS supports LRCO so it doesn't have to.

                                • 13. Re: JBossTS/JBossJCA XA/Local transactions
                                  marklittle

                                   

                                  "bill.burke@jboss.com" wrote:
                                  Furthermore, it is completely idiotic and gay to develop a new and different interface other than JTA if I want to use two non-XA enabled resources in the same unit of work. JTA is a great abstraction and has very tight integration with things like EJB to make your life tons easier.


                                  The abstraction JTA gives is based on ACID transactions. You are proposing to break that abstraction. XAResources are the two-phase participants that can be enlisted in the transaction. Yes, I know you know this, but we're having a discussion here so it's worth pointing this out. Basically you are suggesting that we allow arbitrary enlistment of non-two phase aware XAResources within a transaction and break the protocol.

                                  I think that doing that within JTA is "idiotic and gay". Furthermore, at the moment all of this is academic as far as I am aware. We have no customers who need this. If some come forward, then we can look at the issue, assuming their scenarios cannot be addressed through some other way.


                                  BTW, you're the same guy who tried to argue with me that JTA is useless when you have only one resource in your transaction.


                                  Sorry, not me. Any good JTA implementation covers the 1-resource optimisation, so you don't get the overhead of 2PC. If I said anything it was probably that any good JTA implementation doesn't have to do a lot in this case.


                                  Anyways, there is absolutely nothing wrong with using multiple non-XA resources in same TX if a) you can't make them all XA and/or b) more importantly, you are aware of the consequences.


                                  On that we can agree. They MUST be aware of the consequences.

                                  Forcing users ,for the sake of purity, to refactor their applications when they are aware the problem exists is just plain pompus.


                                  We're not forcing users. We have zero users who need this. The one user who thought he did was able to move to a two-phase approach.

                                  "for the sake or purity"? Well, in this case my definition of "purity" is that it conforms to the protocol and guarantees data consistency in the presence of arbitrary failures. Believe it or not, it is important for customers. Over the years JBossTS has, by itself, generated multi-million dollar revenues. So it has to work. People trust that it will work correctly.

                                  As I said above, if there really are customers out there who simply cannot do their work any other way then we can look at the best way to support this. But at the moment, I don't see the need.

                                  BTW, let's try not to make this personal. Believe it or not, but the exchange Weston and I had last night was very good natured.

                                  • 14. Re: JBossTS/JBossJCA XA/Local transactions
                                    weston.price

                                    The problem as I see it is in terms of the types of configurations/deployments we have today. Unfortunatley, the use of multiple 1PC resources in JBoss is quite common, in fact, I would go so far as to assert this is the *main* type of configuration we see in client deployments.

                                    This is especially true in the area of JMS where the underlying provider is not required to support XA. Further, there are a variety of JDBC resources (some of the more off beat ones) that don't provide XA adapters either.

                                    If we are indeed saying that we no longer support this, or at the very least, it is not supported with JBossTS then we have a real 're-education' situation on our hands. This is independent of what is *correct* being that we provided this behavior before no matter how broken it may have been.

                                    Again, the cost thing is a factor as well. In many situations, XA costs and many times this does not come cheap. Of course they always have the option to use JBossTM, but I don't think we want to be in the business of recommending this.





                                    1 2 Previous Next