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

No Transaction

 
Ankit Doshi
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In case of "NO Transaction Context" - meaning in case of the Supports attribute with no transaction from caller, OR in case of NotSupported or Never attributes - when the method runs under this "NO Transaction Context", the changes done during the method are commited automatically?

For example, say I am running a method withdrawFunds() with NotSupported, the funds withdraw done in the method will be commited instantly - is that Correct?
 
Sub swamy
Ranch Hand
Posts: 121
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interesting..understand that this may not exactly answer your question...

Within a business method, which has multiple hits to DB, we can ensure that execution of several SQL statements are committed together.
When we execute a statement on a connection object, the statement gets commited since is the default. When we say
the set of SQL statements all get committed once we explicitly do the commit.

Now coming back to your question, what if the method withdraw() is called from another method as a part of execution of a set of SQL statements - this method doesn't run within a transaction context, neither is the SQL interaction committed.
 
Ankit Doshi
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm sorry, but I didn't understand it properly.

Do you mean to say if the calling method is somehow doing setAutoCommit(false) then the DB updates done in the withdrawFunds() would not be committed??
 
Sub swamy
Ranch Hand
Posts: 121
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"Do you mean to say if the calling method is somehow doing setAutoCommit(false) then the DB updates done in the withdrawFunds() would not be committed?? " - yes, only when we say setAutoCommit(true) would the set of SQL statements be committed when we use this approach. This is used only for BMT.
 
Ankit Doshi
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's fine with BMT. But what's with CMT? Let's say I am using CMT and my method is attributed as NotSupported. Means, no matter the caller has a transaction associated or not, this method is not going to run in any transaction? What happens in this case? Would the DB updates done in this method be commited instantly?
 
Ankit Doshi
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's fine with BMT. But what's with CMT? Let's say I am using CMT and my method is attributed as NotSupported. Means, no matter the caller has a transaction associated or not, this method is not going to run in any transaction? What happens in this case? Would the DB updates done in this method be commited instantly?
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
With the NotSupported attribute, the EJB method will never take part in a transaction as any incoming transaction will be suspended. You probably need the Required attribute.
 
Ankit Doshi
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
True, method with the NotSupported Attribute doesn't take part in transaction. But that doesn't mean method can't do any DB updates - right? To be more clear, what if the method is having DB update code and doesn't participate in a transaction?
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The Container invokes an enterprise Bean method whose transaction attribute is set to NotSupported with an unspecified transaction context. This means that you can't tell what will happen because the EJB specification does not prescribe how the Container should manage the execution of a method with an unspecified transaction context � this is left to the Container implementation.

Some techniques for how the Container may choose to implement the execution of a method with an unspecified transaction context are as follows (the list is not inclusive of all possible strategies):
� The Container may execute the method and access the underlying resource managers without a transaction context.
� The Container may treat each call of an instance to a resource manager as a single transaction (e.g. the Container may set the auto-commit option on a JDBC connection).
� The Container may merge multiple calls of an instance to a resource manager into a single transaction.
� The Container may merge multiple calls of an instance to multiple resource managers into a single transaction.
� If an instance invokes methods on other enterprise beans, and the invoked methods are also designated to run with an unspecified transaction context, the Container may merge the resource manager calls from the multiple instances into a single transaction.
� Any combination of the above.

Any method with a name like withdrawFunds() clearly needs a transaction, so the use of NotSupported would be wrong.

NotSupported is for use when the method must not be enrolled in the incoming transaction. Think, say, of a logging method which must execute even if the incoming transaction is rolled back.
 
Ankit Doshi
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Roger for explanation. I know the method like withdrawFunds() should have a transaction associated ideally, but this was just to clarify.

I am still not clear on one thing as mentioned below. Though it might be off the exam, but I would be thankful if you can help me clarify my concept...

The first option you have mentioned below is:
The Container may execute the method and access the underlying resource managers without a transaction context.


Let us assume for a moment that the container takes this approach - it executes the method without a transaction context. In this case, though the method is not in any transaction context, still if the method is doing some db updates, it would have to be committed (or rolledback) somewhere - either on every call to the database or at the end of method or something ... What can this be?

To me it looks like it may be container dependent ... What do you think?
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Indeed, it is completely container dependent. Suppose that an EJB method running in an unspecified transaction context does two DB updates. If the first works but the second fails, you have no way of knowing whether the container will rollback the first update. This is why it is important to set the correct transaction attribute for every method.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic