8 Replies Latest reply on Aug 1, 2005 7:03 PM by gregg_saffell

    distributed transactions -- are they or are they not support

    gregg_saffell

      I've read many postings suggesting JBoss 4 has a "full distributed transaction manager" which I take to mean a TM that provides for transactions that span multiple JVMs.

      The JBoss 4.x documentation does not support this. It makes reference only to the "fast in-memory TM" that does not propagate transaction context outside of the JVM.

      There are many and varied postings that talk about using tyrex and jotm but none of those inspire much confidence.

      So does JBoss 4.x include a transaction manager that supports distributed transactions?

      Thanks,
      Gregg

      P.S. Here are some links suggesting this is included with 4.x:

      - This posting says JBoss 4.0 has a "full distributed transaction manager" -- http://www.theserverside.com/news/thread.tss?thread_id=19615

      - This posting says 4.0 has "a full implementation of J2EE 1.4 and distributed transactions" -- http://computerworld.com/developmenttopics/development/java/story/0,10801,83555,00.html

      - This posting suggests that distributed transactions are part of J2EE 1.4: http://java.sun.com/j2ee/1.4/docs/tutorial/doc/

      - As does this one: http://www.theserverside.com/articles/article.tss?l=J2EE1_4 (the jboss site says JBoss 4.0 is J2EE 1.4 certified)

      [/url]

        • 1. Re: distributed transactions -- are they or are they not sup

          Ask yourself, how many of those links are from the actual JBoss site?

          And while you are at it, ask yourself what the JBoss site actually says:
          http://www.jboss.org/wiki/Wiki.jsp?page=JBossJTS

          You can be J2EE certified without supporting JTS.
          EJB-2.1 Section 19.6.2:
          "Interoperability The requirements in this subsection are designed to ensure that when a J2EE container does not support transaction interoperability, the failure modes are well defined so that the integrity of an application s data is not compromised: at worst the transaction is rolled back..."

          JTS Work In Progress:
          http://jira.jboss.com/jira/browse/JBAS-1421

          JBoss with JTS from a partner NOW
          http://www.arjuna.com/products/jboss/index.html

          • 2. Re: distributed transactions -- are they or are they not sup
            gregg_saffell

            Thanks for the quick reply. Having a definitive answer means more than you know.

            The postings regarding tyrex seem to suggest that it was included/recommended at some point in JBoss's history but was subsequently removed/deprecated.

            The postings regarding JOTM seem to suggest that it is the recommended open source alternative but I've found no postings that suggest it has been successfully integrated.

            I need distributed transaction support in the near term. Are either of the above viable with JBoss 3.2.x or 4.x?

            (I'm not averse to doing a little work to make it happen, I'd just like to avoid spending a lot of time only to learn it was never viable to begin with. Also, I'm not talking about a high volume application, just a few concurrent transactions at any given time.)

            Thanks again.

            Gregg

            • 3. Re: distributed transactions -- are they or are they not sup

              Tyrex is broken and does not do transaction recovery.
              Even the original coder said NOT to use it in production.
              Although you can still find the code in the cvs archive, I doubt it even compiles.

              JOTM is based upon HOWL of which most people I've spoken to have a low opinion.

              I know of posts (which you can find using search) where people have tried to
              integrate JOTM and asked for help, but then gave up because:

              * They couldn't get it to work
              * Got it to work, but didn't give any feedback to tell us
              * Gave up trying with no conclusion

              If like these other users you go for JOTM and aren't prepared to
              contribute the integration back to JBoss, you are on your own.

              Useful link:
              http://wiki.jboss.org/wiki/Wiki.jsp?page=3rdPartyTM

              • 4. Re: distributed transactions -- are they or are they not sup
                gregg_saffell

                If we go for it, I'll be sure to post the results--good, bad, or inconclusive.

                Thank you very much both for the reply and for the application server.

                Gregg

                • 5. Re: distributed transactions -- are they or are they not sup

                   

                  "Gregg_Saffell" wrote:
                  I need distributed transaction


                  It is very seldom you actually need DTM (rather than just XA).
                  It usually points to bad design and nearly always leads to poor performance.
                  Besides being a pain to manage.

                  The only reason we are implementing JTS for JBoss is because people insist they need
                  it. They are usually wrong. I would never recommend that somebody actually uses it.

                  But people will always argue that we don't recommend it because we haven't got it.
                  The answer will be the same when we implement it.
                  Just like some of the other brain deaths in the spec...
                  http://wiki.jboss.org/wiki/Wiki.jsp?page=HowCanIAccessADataSourceFromAClient

                  • 6. Re: distributed transactions -- are they or are they not sup
                    gregg_saffell

                    That "it only points to bad design" has been posted before and isn't true. We have a distributed application that requires a record to be stored both locally and at a remote site. The redundant storage of the record allows both sites to do their thing even when they can't communicate. Should the two databases get out of sync, the app is compromised. Lastly, they have to communicate over https.

                    The http invoker servlet is awesome by the way, really came in handy. That's the other piece the worries me though. I'm concerned that even if we do successfully integrate JOTM we'll then only learn that the invoker servlet doesn't propagte the transaction context. Do you know if it will or won't?





                    • 7. Re: distributed transactions -- are they or are they not sup

                       

                      "Gregg_Saffell" wrote:
                      That "it only points to bad design" has been posted before and isn't true. We have a distributed application that requires a record to be stored both locally and at a remote site. The redundant storage of the record allows both sites to do their thing even when they can't communicate. Should the two databases get out of sync, the app is compromised.


                      My point exactly. Why wouldn't two applications that can't communicate NOT get out of sync. And how are you going to recover them consistently when they can't communicate
                      with each other? etc.

                      I'm not going to go further down this road. Your application design is your problem.


                      Lastly, they have to communicate over https.

                      The http invoker servlet is awesome by the way, really came in handy. That's the other piece the worries me though. I'm concerned that even if we do successfully integrate JOTM we'll then only learn that the invoker servlet doesn't propagte the transaction context. Do you know if it will or won't?


                      Why would JOTM/JTS which is CORBA know anything about HTTPS or JBoss's invokers other than RMI/IIOP?
                      I think it is time you go back and re-read the specs and links that I gave you before,
                      rather than using me as your search engine.

                      • 8. Re: distributed transactions -- are they or are they not sup
                        gregg_saffell

                        I'll take that as a no.

                        Have a nice day.