Do you develop on GitHub? You can keep using GitHub but automatically sync your GitHub releases to SourceForge quickly and easily with this tool so your projects have a backup location, and get your project in front of SourceForge's nearly 20 million monthly users. It takes less than a minute. Get new users downloading your project releases today!
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:(
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?
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
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
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
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.
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.
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.
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.
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.
not now (Score:1)
Re:not now (Score:1)
Re:not now (Score:1)
Re:not now (Score:1, Informative)
question: why transactions in app server? (Score:2, Interesting)
Re:question: why transactions in app server? (Score:2)
You misunderstand J2EE (Score:1)
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 (Score:2)
They cross DB boundaries (Score:5, Informative)
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? (Score:4, Informative)
Note that it's not only databases that use transactions, Slide f.e. can support transactions at the HTTP level.
What was absent before? (Score:1)
Re:What was absent before? (Score:1)
Re:What was absent before? (Score:4, Informative)
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? (Score:2, Informative)
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? (Score:4, Informative)
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]