Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Benefit of transactions without persistence

 
David Follow
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

in a mock I got asked if it still makes sense to use transactions even tough there is no persistent data nor a legacy system to connect to (not really a real life question, ist it). The answer was "yes"...

However, I have my doubt about that answer.
What are EJB-Tx good for if I don't have data to persist? As far as I know, Session Beans do not role back their state (applicable for SFSBs) once a Tx roles back, does it? Therefore what is the acctual benefit of Tx in such a senario? Further, if I don't need persistence, no Tx and no high availability I might as well design a jsp/servlet application. A good app server such as WebLogic does high availability since you can cluster jsp/servlet based applications as well.

So back to my question.
I believe if I don't have persistent data I don't need transactional support neither.

What do you think?

D.
 
Joseph Zhou
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Most time you are right, but there is one more stuff can be transactional: JMS.
 
Byron Estes
Ranch Hand
Posts: 313
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm as confused as you are...

Let's think about transcations in general.

You've heard the term ACID applied to transactions right?

Atomicity - The entire sequence of actions must be either completed or aborted. The transaction cannot be partially successful.

Consistency - The transaction takes the resources from one consistent state to another.

Isolation - A transaction's effect is not visible to other transactions until the transaction is committed.

Durability - Changes made by the committed transaction are permanent and must survive system failure.

In looking at that, I can't envison any benefit only cost to using a transaction when there's nothing to persist.

You use transactions to make it easier back out changes. A rollback is simpler to use and maintain than a copensatory transaction (another separate transaction that reverses what you just did.) If you aren't updating something somewhere then there's nothing to worry about being inconsistent. There's nothing to worry about issolating, beacause it can't impact anything else if it's not persisted to an external store. Durabaility speaks for itself.

As far as the other post about JMS, that really doesn't make sense to me.
Transactions work on resources that comply with the transactional method , usually XA specification. The transactional resource is not just limited to a database. It is any resource that has been exposed in such a way that it complies with the transactional interface so that it can participate in either a local or distributed (2-phase commit) transaction. Message queues that support transactions are no different than databases in this regard. They also persist messages which can be committed or rolled back and exhibit ACID properties...and guess what most of them are implemented using a database.
 
Joseph Zhou
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let's look at Sun's J2EE Bible: Designing Enterprise Applications with the J2EE Platform, Second Edition, at page 253:

8.1.2 Transaction Participants
An application that uses transactions is called a transactional application. In a J2EE application, a transactional application may consist of multiple servlets, JSP pages, and enterprise beans. A resource manager is an external system accessed by an application. A resource manager provides and enforces the ACID transaction properties for specific data and operations. Examples of resource managers include a relational database (which support persistent storage of relational data), an EIS
system (managing transactional, external functionality and data), and the Java Message Service (JMS) provider (which manages transactional message delivery). A transactional application accesses a resource manager through a transactional resource object. For example, a JDBC java.sql.Connection object is used to access a relational database. A resource adapter is a system library that makes the API of a resource manager available to an application server. A Connector is a resource adapter that has an API conforming to the Java Connector architecture, the standard architecture for integrating J2EE applications with EISes.
 
Byron Estes
Ranch Hand
Posts: 313
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
All of which (JMS, EIS, Database) make changes to data in their scope that needs to be persisted based upon a commit or backed out based upon a roll back.
 
David Follow
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just by looking at the definition of Durability

Durability - Changes made by the committed transaction are permanent and must survive system failure.

It doesn't make any sense to have Tx without data to persist, either through JDBC, JCA or JMS...

Thanks folks, that pretty much answers my question.

D.
 
Joey
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi David,
That means that the answer to your mock exam was correct and the questions answer was wrong indeed.
We really need to cope up with these kind of issues also
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic