Transaction Attributes

[Vipin Mohan]

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

[Nicky Moelholm]

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.

[Mikalai Zaikin]

hey, Nicky !
excellent explanation !

[Vipin Mohan]

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

[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.

[Vishwa Kumba]

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?