In Page 351 of the EJB 2.0 Specs, it is stated that "Transaction attributes must not be specified for the methods of a session bean�s home interface." However, we can specify trans. attributes for the methods of an entity bean's home. Why is this difference ? thanks vipin
Hi Vipin, When you invoke create or remove on a stateless session bean - it doesn't necessarily mean that the server invokes the corresponding ejbCreate or ejbRemove on the bean instance. So seen in that perspective it doesn't make any sence to allow for the client to specify TX behavior. However, with entity beans, it is another story. When you invoke create, remove etc. on an entity beans home interface it actually means that something is happening in the database (according to the containers strategy this can postponed to TX commit time, etc.). If that wasn't under your TX control then it wouldn't be reliable (or useful at all). Hope it gives you a "logical" view on those two different cases.
MyCerts: SCJP 1.2, SCJP 1.5, SCJD, SCWCD 1.3, SCBCD 1.3, SCDJWS 1.4, SCEA, IBM 253
MyBooks: IBM WebSphere Application Server V7.0 Web Services Guide
Exam 1Z0-817: Upgrade OCP Java 6, 7 and 8 to Java SE 11 Developer Study Guide and Quiz
posted 17 years ago
hi Nicky Thanks for the answer. However, I still have a question. A client call to create() does not cause a call to ejbCreate(), this is only for stateless session beans. What about stateful beans then ? For them create() and remove() are delegated to the bean's ejbCreate() and ejbRemove() methods. So should't transaction attributes be set for these methods in the case of stateful session beans ? Thanks Vipin
Originally posted by calvin zhu: well, there are could be no need for session beans to use transcation at all( though they might). For example, a stateful session bean could be just a calcualtor without ever calling the database.
-Say if I have a SFSB that does some database updating activity in the ejbCreate()/ejbRemove() method and if the method throws a runtime exception, my transactions are still committed As the methods execute in an unspecified transaction context, can I assume that the container will likely perform a rollback operation in the above scenario?
To do a great right, do a little wrong - shakepeare. twisted little ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop