JBoss Adds Full Transaction Support

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

not now

[free space]

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

Re:not now

[thedude79]

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

Re:not now

[free space]

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 :(

Re:not now

[Anonymous Coward]

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

question: why transactions in app server?

[free space]

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?

Re:question: why transactions in app server?

[curious.corn]

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

You misunderstand J2EE

[Julian Morrison]

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

Re:You misunderstand J2EE

[curious.corn]

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 functi

They cross DB boundaries

[Julian Morrison]

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.

Re:question: why transactions in app server?

[GuyWithLag]

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.

What was absent before?

[hayriye]

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

Re:What was absent before?

[ciroknight]

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.

Re:What was absent before?

[aminorex]

That's just wrong.

What Arjuna supports are WS-CAF [oasis-open.org] 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.

Re:What was absent before?

[Kevin Conner]

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 [arjuna.com]

Re:What was absent before?

[Eric Giguere]

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 [ericgiguere.com]