This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
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

Advantages of Transactions.

 
Treimin Clark
Ranch Hand
Posts: 757
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A simple question
But I'm confused with this.


What are the advantages of using transactions (CMT/BMT) on beans. And, what is the disadvantage, if there are no any transaction and the bean methods are being invoked just like a normal method invocation?
 
Raf Szczypiorski
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I will try to answer in my words, how I think of it.
Your beans encapsulate business logic. In the logic, you may use many resources, like databases, LDAP directories, JMS, ... You want all of the changes you make to be atomic, so that when you add something to a database, and then do some LDAP changes as well, and LDAP fails, you want the database changes not to be actually committed. So, to do that reliably you use a transaction manager. This is where JTA comes in - it provides you with a UserTransaction that the resource managers can be enlisted to. If the whole transaction commits, all of the resources commit. If at least one rolls back / fails for some other reason, all of the changes are rolled back. That's what distributed transaction is for.
Now, you can use a UserTransaction (BMT) if you like, but you can also employ the container to do the work for you. CMT is probably using UserTransaction behind the scenes, but you, the developer, are relieved from the necessity to remember about transaction handling. Also, it enables easier development model, where even a JEE developer who is inexperienced in transaction processing can develop a bean, and transaction support may be added in the deployment descriptor by a guru.
Just think of it as you do about container-managed vs application-managed persistence context - you can use both, but if you go for the container, it will do some things for you - close, flush, open, propagate the context with transaction, enlist in a transaction... Handy, isn't it? But you also loose some flexibility, that's why you are also allowed to fall back to application-managed context if needed.

Raf
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Guys,

Transactions help enforce ACID properties as described here: http://en.wikipedia.org/wiki/ACID.

Regards,
Reza
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The most important advantage of using transaction is atomicity (A from ACID).

Let's say, you have table A and B, you want to update table A and B in a unit of work, if you can update table A, but failed to update table B, you'll want to rollback. By using transaction, rolling back is easy.
 
Raf Szczypiorski
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Did I sound as if I don't know what ACID is? I just wanted to tell what transactions are in regard to EJBs. I am not sure if Traimin's question is so high-level as what transactions are in general?
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Raf,

I honestly think you are over-reacting here. There is no offense or disrespect intended, sorry if any was perceived. I am merely pointing out that transactions in EJB pertain more to simply maintaining atomicity. In fact, I would say the isolation property is really what is most important for most Java EE applications because they are inherently multi-threaded. Atomicity is the most touted and easiest to explain to a beginner, so I can understand your response.

Best regards,
Reza
 
Raf Szczypiorski
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is a misunderstanding, I am not feeling offended in any way... Sorry if my post implied something like this, I should have added an emoticon or sth to make it look more friendly. I just honestly thought that Traimin was asking for an easy and general explanation, and I thought that this example was the easiest to digest. Really, no offense taken and hope you are not angry either, as you are the authority around here ;-)

Peace.
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Raf,

Glad to hear it, one reason I am on JavaRanch is that it really is a "friendly place". Maybe I should have made my initial response more detailed in the first place. Honestly, I am just pressed for time.

Believe me, I understand your response. In fact, this is one of the things that I argued with my co-authors about while writing the book. And we settled on the atomicity example because it was the easiest to understand...

Cheers,
Reza

P.S.: I really don't see myself as an "expert" or "authority" anywhere, let alone JavaRanch. In my experience, it is a wrong-headed attitude. Everyone can make mistakes, overlook something or just plain not know about something :-). As Socrates said - "As for me, all I know is that I know nothing" :-). And I consider Socrates a pretty smart dude :-).
 
Raf Szczypiorski
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I probably used a wrong word, by "authority" I did not mean you are the guy who sets the rules here, but "a person who has a lot of respect from others". It couldn't find the right word and my dictionary failed, abviously, as in my language the word is very similar actually. I believe this is called a "false friend" in English.
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Raf,

Understood and thanks for the kind words :-).

Cheers,
Reza
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think it's depend on point of view that in ACID what is the most important .

If we say Isolation is the most important, what happens if when transaction rollback, but it doesn't rollback any changes before the error occurred (doesn't have atomicity)?
Without atomicity, consistency cannot be maintained as well.

Durability is also important, without it after committed we could not ensure that database will get updated if system failure happens.

Hm, I think let's say it's all important, and when explain transaction we should explain all properties in ACID.
 
Treimin Clark
Ranch Hand
Posts: 757
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oh! I've got surprised when I see these answers to my little question

Thanks to Raf, Reza, and Kengkaj.

And I'm sorry if this question is a nonsense.
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Treimin,

Clearly the question is not nonsense :-). Now when the topic of transactions in Java EE comes up, you'll have quite a bit to say about it:-).

Cheers,
Reza

P.S.: I agree all the ACID properties are very important.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic