Home

News: Arjuna Releases Distributed JTS and JMS Services for JBoss

  1. Arjuna are pleased to announce the release of the Arjuna+JBoss product which integrates Arjuna’s distributed transaction service (JTS) and messaging service (JMS) with the popular JBoss application server.

    Arjuna’s extensions ensure data integrity for business-critical applications even in the presence of concurrent access and occasional component failures. With Arjuna+JBoss customers can implement complex distributed transaction-based applications that are totally protected by Arjuna’s automated recovery processes. Should a failure occur, system data integrity will be preserved without the need for costly manual intervention.

    Arjuna’s transaction processing and reliable messaging components are the former core engines from the Hewlett-Packard and Bluestone Software application servers. Arjuna’s transaction service adds fully distributed transactional support using two-phase commit coordination to JBoss, thereby allowing distributed transactions to span application server instances and multiple heterogeneous data sources. The Arjuna Message Service provides a reliable, secure, high performance messaging solution, which, through the XA-compliant interfaces, allows JMS application code (including Message-Driven Beans) to fully participate in distributed transactions.

    Evaluation versions of Arjuna+JBoss are now available for download from http://www.arjuna.com.

    Read the full press release (PDF) for more information.

    Threaded Messages (18)

  2. Why post this?[ Go to top ]

    Should I post the latest commercial JSSE plugin for WebSphere.
    Or the cache solution for Oracle?
    Or the monitoring product for WebLogic?
    Why post this?
  3. Why post this?[ Go to top ]

    How many JTS compliant transaction monitors are out there? This is a different breed of product. It puts JBoss on the map for distributed transactions. I don't know how JBoss does 2pc today but Arjuna is high quality and the developers have a reputation.
  4. Why post this?[ Go to top ]

    Oh, Marc, why don't you just give up the aliases and post as yourself?

    Anyway, since you probably have an inside angle on this - how much does Arjuna JTS cost?

        -Mike
  5. Why post this?[ Go to top ]

    I am not Marc (but am flattered anyway). Your hate for Marc Fleury and JBoss is making you jump to conclusions. Continue down this path and you will make a big faux pas someday. (again, just because I said "faux pas" doesn't mean I am Marc ;-)
  6. Why post this?[ Go to top ]

    Um, sure, everybody in the Java world uses phrases like "This seems like an open challenge to the JBoss jedi knights".

    Also, a slight correction: I don't hate you or JBoss.

        -Mike, awaiting the noisy....
  7. Why post this?[ Go to top ]

    a a: Should I post the latest commercial JSSE plugin for WebSphere.
    Or the cache solution for Oracle?
    Or the monitoring product for WebLogic?
    Why post this?


    First, I love your name. I just wanted to tell you it's been 8 days for me without a drop.

    Second, you can post whatever you want. I can't keep acronyms straight, but JSSE sounds Java related, so post it. The "editors" at TSS will let some through if they look interesting, and bin the rest. They get lots of submissions, and try to pick stuff that's interesting to the community.

    Third, it's about JBoss, and that draws attention. Maybe the wrong kind of attention, but attention nonetheless. JBoss always stirs up controversy -- just look at this thread!

    Fourth, I don't know didley about Arjuna, but if it does distributed 2PC and JMS and stuff like that for JBoss (or other J2EE servers) then it's probably interesting to at least some of the people reading this site. It certainly seems to be on topic for this site.

    Now, if we could just get Marc to contribute an SMD comment or two, we'd be off to the races ....

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  8. ??[ Go to top ]

    At one of our projects we used JBoss, and we had to use 2PC protocol. I can't tell standard (or, read, bundled) JBoss solutions didn't do the job. So why is this submission represented as a 'totally new add-on'?
  9. ??[ Go to top ]

    At one of our projects we used JBoss, and we had to use 2PC protocol. I can't tell standard (or, read, bundled) JBoss solutions didn't do the job. So why is this submission represented as a 'totally new add-on'?


    Out of the box vanilla JBoss doesn't do distributed 2PC or failure recovery. It certainly does have support for two-phase commit in that you can register multiple resources with the coordinator and it'll go through prepare/commit/rollback, but that's only a subset of what's required for distributed two-phase.

    Mark.
  10. ??[ Go to top ]

    Out of the box vanilla JBoss doesn't do distributed 2PC or failure recovery.

    It certainly does have support for two-phase commit in that you can register multiple resources with the coordinator and it'll go through prepare/commit/rollback, but that's only a subset of what's required for distributed two-phase.
    >

    That is right, Arjuna TM is an excellent product. I don't just say it because they are partners but the ex bluestone technology and guys found their way there and they managed to put a very relevant product on the market. Mark you should talk about references.

    JBoss found out that 2PC recovery is used by few people that usually have the cash to pay for these features. Instead of doing it in open source (which is difficult) this is a good example of a add-on to JBoss that brings tremendous value and is worth the dollars.

    If 2PC distributed recovery is your thing they arjuna on JBoss is your thing

    </commercial>

    marcf
  11. ??[ Go to top ]

    \marc fleury\
    JBoss found out that 2PC recovery is used by few people that usually have the cash to pay for these features. Instead of doing it in open source (which is difficult) this is a good example of a add-on to JBoss that brings tremendous value and is worth the dollars.
    \marc fleury\

    What a load of horse manure. Open source can write a CMP implementation. Open source can create Hibernate. Open source created Mozilla. Open source can create freakin' Linux. But it can't implement a simple transaction log? As usual, yer full of it, Marc.

    All rants aside, JBoss could easily create a halfway decent transaction log with a few weeks of effort. Hell, you could even steal the log design and recovery algorithm I've publically posted! It's clear to me that JBoss Group LLC doesn't do so for the sole reason that reliable, fast solutions aren't sexy enough to put into a press release.

         -Mike
  12. ??[ Go to top ]

    So why don't you contribute the solution? Sounds like you have the expertise (you already have the log design and recovery algorithm) and would not take very long (according to your estimate).
  13. ??[ Go to top ]

    So why don't you contribute the solution?

    Mike mentioned elsewhere that he is thinking about contributing such a thing, although probably under a looser license than LGPL (i.e. not directly to the JBoss project.) Either way, that code could be used in the JBoss project, since LGPL can re-purpose Apache-style licenses (just not vice versa, as we saw with JBoss/Elba/Geronimo.)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  14. ??[ Go to top ]

    I've only just recently negotiated an agreement with my employer which allows me to work on select open source projects, and getting individual approval for "affiliated" projects (e.g. under the auspices of an organization like ObjectWeb, Apache, Jboss, etc) is a PITA. These are all strong motivators for me to pick and choose what I do (and with whom) carefully. And, frankly, JBoss at this moment in time is probably somewhere below the bottom of the list.

    In addition, as Cameron indicated I'm not a fan of the GPL or LGPL. I think ultimately those licenses inhibit progress more than they engender it in the large scheme of things (e.g. not just in open source, but for the entire industry, commercial, open, and in-betweeners). For me, I strongly prefer the BSD license, and I will endeavor to release anything I do under BSD whenever possible.

    That's two strikes against JBoss. The third strike is the recent JBoss and Geronimo legal flap. Mr. Fleury was careful to only include code in his letter that he (thought) he authored, but others employed by JBoss Group LLC, most notably Bill Burke, have repeatedly attempted to assert ownership and copyright rights of the JBoss codebase in public forums like this (though, fortunately for them, they haven't tried this via legal channels). I would be mortified beyond words if a Bill Burke attempted to claim his company owned my code. Not that there is much protection in the court of public opinion - JBoss Group tried to claim ownership of some Apache log4j code, so no one is truly safe :-/

    In any case, I may release some logging and recovery code sometime in the near future. If I do so, it will be independently released under a BSD license, which means that anyone can use the code if they wish, be it Geronimo, JBoss, JOTM, or your friend's Aunt Sally. So long as they retain my copyright notices in the code :-)

    Due to the nature of transactional logging and the JTA spec, it would probably take about a day of light work for someone to integrate such a logger into their TM (probably less, but I'm willing to make allowances). Figure another couple of days to implement the core of the recovery algorithm outlined in my blog entry "XA Exposed, Part II".

    Refinements beyond that would be on-going and incremental in nature. You'd want monitoring hooks to optionally propogate rollback information, heuristic conflicts, etc. A console to show transactional state. An interface for attempting to manually resolve inconsistent transactional states, or to clear locks if one or more XAResource is offline. Tweaking the code to work with the sometimes bizarre misinterpretations of the XA spec with regards to the recover() method (hi, Oracle :-). Pluggable log implementations, configuration, policies, etc. etc.

    The thing to keep in mind is that compared to, say, a JMS implementation, or pre-existing JTA/JTS implementations, or doing CMP entity beans, such a logging and recovery mechanism is a walk in the park. Marc Fleury's assertion that this is something that shouldn't be done by open source, but is best left to commercial products, is ludicrous.

        -Mike
  15. ??[ Go to top ]

    I think that would be great if you could contribute something like that to open source (not trying to imply you that you have not already, just not aware of anything). Who cares under what project or license you do it.
  16. don't fix it if it works[ Go to top ]

    Whatever you've said, JBoss still does the job. If a distributed 2PC is not such a rare case, could you please point me to the resources (probably spec or discussion) on the issue?

    Thanx in advance.
  17. don't fix it if it works[ Go to top ]

    Whatever you've said, JBoss still does the job. If a distributed 2PC is not such a rare case, could you please point me to the resources (probably spec or discussion) on the issue?

    >
    > Thanx in advance.

    Andrew, I'm not sure what resources you're on about, but the following may help:

    (i) Jim Gray's book Transaction Processing Concepts and Techniques
    (ii) Eric Newcomer's book Principles of Transaction Processing
    (iii) the OMG's OTS specification
    (iv) the X/Open XA DTP specifications
    (v) lots of papers from industry and academia on distributed transactions and recovery (just try a google search)
    (vi) There's an upcoming book from Greg Pavlik, Jon Maron (both Oracle) and myself that covers this subject in a lot of depth.
    (vii) perhaps some of the WS-T/WS-TXM stuff, but that's web services specific (still has the same issues though).
    (viii) the OTS mailing list, but I don't know if that's publicly available.

    If you want something more specific, just let me know.

    Mark.
  18. don't fix it if it works[ Go to top ]

    If a distributed 2PC is not such a rare case, could you please point me to the resources (probably spec or discussion) on the issue?

    Just to clarify, JBoss supports 2PC, but (what Mike is talking about) it's not a recoverable transaction manager, meaning if JBoss dies during 2PC processing, the transactions that were being prepared/committed in the databases (or whatever the resource managers were) need to be rolled forward or back manually, because when JBoss restarts it won't have any idea that it died leaving transactions in various stages of completion.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  19. don't change the oil[ Go to top ]

    At one of our projects we used JBoss, and we had to use 2PC protocol. I can't tell standard (or, read, bundled) JBoss solutions didn't do the job. So why is this submission represented as a 'totally new add-on'?

    There's a call in show on NPR called Car Talk. It's about two guys named Click and Clack living in Cambridge, Massachusetts that work on cars, and they like to laugh a lot. Anyway, one day this lady calls in and asks when she should change her oil. They asked her what kind of car she has ... she said "Buick LeSabre" (or something like that.) They asked what year it was ... "1993." They asked her if she was having trouble with it ... "Nope, none at all," she said. They asked how many miles it has on it ... she answered "Eighty-seven thousand." Then they asked when she last had the oil changed ... and she said, "Well, I've never had the oil changed." Silence. You could have heard a pin drop. All of a sudden they burst out laughing, and say "Don't change the oil, don't ever touch the oil."

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!