Slashdot Mirror

← Back to Stories (view on slashdot.org)

JBoss Adds Full Transaction Support

Posted by Hemos on from the suiting-up-for-battle-wtih-Big-Blue dept.

thedude79 writes "JBoss adds full transaction support by buying Arjuna - as listed in their product definition and the buyout announcement."

17 comments

  1. not now by free+space · · Score: 1

    They say in the article that it's by the first quarter of 2006, until they integrate the ArjunaTS software they acquired.

    1. Re:not now by thedude79 · · Score: 1

      yeah but it's coming......that's the point!

    2. Re:not now by free+space · · Score: 1

      yeah, but both the original poster and the JBoss site speak like it's already here. The JBoss site even calls it 'JBoss transactions' and talks about how they provide training and support for it like it's been available for ages :(

    3. Re:not now by Anonymous Coward · · Score: 1, Informative

      Actually, Arjuna's transaction manager has worked with JBoss for years. What's new is that it will now be open source.

  2. question: why transactions in app server? by free+space · · Score: 2, Interesting

    Pardon me if this is a newbie question, but what does it mean when there is transaction support in the application server? what's it's difference from using transactions in the underlying DBMS?

    1. Re:question: why transactions in app server? by curious.corn · · Score: 1

      I don't think there is any. Personally I think J2EE is a bloated, over-complicated heap but for Sun it makes sense to have it. It makes it possible to transfer all the business rules away from the dbms and into the java server domain, thus making all the stored procedures, trigger, dbms specific pl languages redundant (or the other way around, it's J2EE that's redundant). Taken to all the possible extent you can dump the db in a bunch of flat files; ok, that's bull, but really, with J2EE you pry your balls out of Oracle's greedy hands. If you take it from this perspective, J2EE is not bad at all; for Sun it levels the power struggle with Oracle and for you, it gives the option to build your business on a freer platform

      --
      Mi domando chi à il mandante di tutte le cazzate che faccio - Altan
    2. Re:question: why transactions in app server? by GuyWithLag · · Score: 3, Informative

      These kinds of tech are necessary when you aggregate several "products" into a "solution", each "product" requiring its own database or database-like system. This gives you recoverable transactions across databases (well, usually).

      Note that it's not only databases that use transactions, Slide f.e. can support transactions at the HTTP level.

  3. What was absent before? by hayriye · · Score: 1

    If it was not full, something must be absent in transaction handling before. Was it mission critical?

    1. Re:What was absent before? by ciroknight · · Score: 0

      Transactional Databases are mission critical to a lot of applications, and JBoss (I believe) had no transaction support before. What they mean by "full" transaction support is that all of the transaction elements that are declared nessicary by the SQL standard are going to be supported by JBoss through this recent acquisition.

      --
      "Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
    2. Re:What was absent before? by aminorex · · Score: 3, Informative

      That's just wrong.

      What Arjuna supports are WS-CAF and WS-TX. These are protocols which abstract the implementation of transactions. They can be supported regardless of the data storage technology used by the application server.

      Bringing these technologies into the open source world means that many enterprises will now be newly able to operate entirely without proprietary software technology, if they so choose. Enterprises ranging from webshops to Fortune 500s to national government departments.

      --
      -I like my women like I like my tea: green-
    3. Re:What was absent before? by Eric+Giguere · · Score: 3, Informative

      All application servers are transactional in the simple case, where all the operations actually affect a single database. In that case the application server's transaction maps to the database server's concept of a transaction and things are very simple.

      The difficulties arise when you're doing operations that involve more than one database or a database and some other type of software. For example, say the business logic does two things: it updates a database record and it sends an SMS message to a mobile device informing it of the update. Ideally, you want to wrap those two operations in a single transaction, so that if the udpate fails no message gets sent and vice-versa. Of if the update succeeds but the system goes down then on wakeup the system continues and sends out the message, or else rolls back the whole thing.

      That's what this stuff is about.

      Eric
      See your HTTP headers

    4. Re:What was absent before? by Kevin+Conner · · Score: 2, Informative
      CAF and TX support is only a part of the acquisition, JBoss have also acquired the JTA and JTS implementations.

      They now have the facility to manage distributed transactions with logging and recovery, locally or via OTS.

      See the Arjuna site for more details. http://www.arjuna.com/products/arjunats/index.html

  4. Re:Zealotry at its finest by Anonymous Coward · · Score: 0

    It's just as shitty if you use Linux and Opera.

  5. They cross DB boundaries by Julian+Morrison · · Score: 4, Informative

    A typical use of J2EE transactions would be an app that needs to modify in-memory objects, modify local SQL data, modify remote data via a defined abstract interface with limited permissions, and do it all as one transaction, succeed or fail atomically. J2EE transactions make that possible, and in some cases easy.

    It's an "enterprise" thing. If your business is large enough to be horizontally partitioned into departments with seperate IT, then you'll probably need it. Otherwise, probably not.

  6. You misunderstand J2EE by Julian+Morrison · · Score: 1

    Their transaction support isn't there to supplant database transactions. In fact it implicity creates them. It's there to combine those transactions and other activities into a single "business transaction" that can span mutiple DBs, mutiple running apps, and activities not normally seen as transactional such as altering in-memory state.

    If you're doing your stored procedures and triggers in the J2EE server, that's just wrong. The result would be a weak, memory hogging duplicate of DB functionality. It's as stupid as doing a "select foo.*, bar.* from foo, bar" and filtering it manually. You're using a screwdriver to hammer nails.

    1. Re:You misunderstand J2EE by curious.corn · · Score: 1

      You're saying that J2EE wraps dbms functionality making it possible to map database and application boundary crossing to the java server tier. Business components (possibly originating from different vendors and integrated by yet another one) that collaborate at the J2EE layer can (theoretically) swap underlying dbms rather than force the entire system to a single one, had they relied on vendor specific features. Your statement about db duplication is correct and nobody should do without standard SQL functionality but, please note, I was half-joking when I mentioned flat files. So essentially we both agree that J2EE is a tough beast that takes the stranglehold away from Oracle; this is a Good Thing, look what happened to the Microsoft Windows and Office platform. I like the screwdriver analogy myself and take great pleasure at mentioning it whenever I can but I don't think it's appropriate this time (speaking of which, I prefer "driving a screw with a hammer", it suggests a more clueless-savage tone to the picture).

      --
      Mi domando chi à il mandante di tutte le cazzate che faccio - Altan