• Post Reply Bookmark Topic Watch Topic
  • New Topic

pro of having short transactions

 
vu lee
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Suppose I have a long method in which every line of code involved transaction called foo(). I then refactory this method into three methods called A(), B() and C(), so now foo() would look like this
foo(){
A(); //transaction attribute: required new
B(); // required
C(); //required
}
Just from the transaction perspective (not other perspectives), what are the advantages of doing this?
 
Mark Spritzler
ranger
Sheriff
Posts: 17290
9
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From a transaction viewpoint- you still will have just one transaction for the duration of the process. It is just cleaner code that sets up the possiblility of re-use, and will also be a bit easier to maintain.

Mark
 
vu lee
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1. If this is the case, then again just from the transaction perspective, the transaction monitor must do extra work to coordinate sub transactions in method A(), B(), and C(). How do you justify the extra work (overhead)?

2. The general advice of keeping the transaction as short as possible is not quite clear as demonstrated by your answer. Should I think it as keeping the unit of work as short as possible?

In an J2EE application, what is the recommended way to determine a unit of work of a process at runtime?
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!