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

transaction behaviour of private method in bean

 
Yi Meng
Ranch Hand
Posts: 270
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
we know that we are not allowed to specify a transaction attribute for private method in bean class, so how will they behaviour with respect to transaction?
If the caller method is not in a transaction, the private will of course be not in a transaction. but what if the caller method is in a transaction, will the private method also be part of the caller's transaction?
 
Vishwa Kumba
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Yi Meng:
What if the caller method is in a transaction, will the private method also be part of the caller's transaction?

Even I couldn't find this in the spec, So I would assume that the private methods always execute in their calling/parent method's transaction context.
 
calvin zhu
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I guess only for stateful session bean, this situation will happen. Since this kind of bean's trandscation can cross multi-methodes.
[ January 15, 2004: Message edited by: calvin zhu ]
 
Keith Rosenfield
Ranch Hand
Posts: 277
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with Vish.
Calvin said
I guess only for stateful session bean, this situation will happen. Since this kind of bean's trandscation can cross multi-methodes

My understanding is that only, bean-managed stateful session beans, can start a transaction in one method and finish it in another. But all stateful session beans can propagate their transaction context to other methods, either their own or belonging to other beans.
Hope this helps.
 
Reid M. Pinchback
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Yi Meng:
If the caller method is not in a transaction, the private will of course be not in a transaction. but what if the caller method is in a transaction, will the private method also be part of the caller's transaction?

I think its important to keep track of when the container is in a position to intercept a method call. E.g.
- Remote client calls public method on EJBObject
(container can intercept, and control transactionality)
- Local bean calls public method on EJBLocalObject
(container can intercept, and control transactionality)
- Same bean instance calls private method from public method
(container has no knowledge, cannot intercept)
- Same bean instance calls public method from public method
(if the bean doesn't go through an EJBObject or EJBLocalObject,
the container has no knowledge, cannot intercept)
Issues of controlling the transactional behaviour only matter to the container. If a line of code lives in a public method, or is moved into a private method called by the public method, or the private method code inlined by a java compiler, none of that matters to the container.
If the container thinks the current public method invocation is happening in the context of a transaction, then everything that method does without going back through the container is happening in the context of a transaction. From an implementation standpoint, the transaction is probably associated with the thread of execution (one reason why enterprise beans aren't supposed to spawn threads).
 
Kathy Sierra
Cowgirl and Author
Rancher
Posts: 1589
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Reid M. Pinchback:

transaction. From an implementation standpoint, the transaction is probably associated with the thread of execution (one reason why enterprise beans aren't supposed to spawn threads).

Yep, the transaction is *definitely* associated with the thread. So picture a stack... and imagine that any private methods (or methods of other non-bean classes) that the bean calls are on the same stack (so, run by the same thread) and thus they get the same transaction context. So, the way Keith explained it was correct -- while only stateful beans with BMT can keep a transaction alive over multiple client invocations, ANY bean in a transaction will propogate its transaction (because the tx is associated with the thread) to any other calls it makes, including calls to other beans.
The only time the called method will *not* be in the same transaction context as the calling method of the bean, is when the method is another bean method, and that method is either in a BMT bean or a method of CMT bean where the method has a transaction attribute of NotSupported, Never, or RequiresNew.
I hope I am making sense! I am, even as I type this, sitting in the final day of the exam creation/development workshop for Sun's upcoming Sun Certified Mobile Application Developer exam. So my brain is completely fried
I am hoping that I will be more coherent again this weekend. And we will not be developing any NEW exams for a while, so I get a brain break after this one.
Cheers,
Kathy
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic