posted 16 years ago
Hi Joseph,
The answer is not very intuitive, or at least it was not for me. There are several reasons that might make this choice very legitimate, starting from a design standpoint, arguing that entity beans are an OO view of the data; therefore they might know nothing about the transactions surrounding them. Another reason may also be the fact that if entity beans will be allowed to demarcate transaction boundaries in an arbitrary way, then things will become far too complex (imagine bean reuse, caching pooling, etc within this context). There is one more scenario that I�d like you to consider: imagine that an entity bean can start/stop its own transaction. Now considering that entity beans are also re-entrant, it might be possible for a client to start a transaction, calling bean A, which calls bean B that calls bean A again. Now if A could independently start its own transaction you might face the situation where the client is initiating a nested transaction. But J2EE doesn�t support nested transaction either ...
Regards.
I think, therefore I exist -- Rene Descartes