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?
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.
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).
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
Those who dance are thought mad by those who hear not the music. This tiny ad plays the bagpipes:
Devious Experiments for a Truly Passive Greenhouse!