EJB transactions are a wonderful. The fact that a bean deployer (who may not have written the bean) can decide on a particular bean's (and method for that matter) transaction attribute (Required, RequiresNew, etc.) is really nice. However, without knowing the actual bean implementation, and what a calling bean is doing transaction wise with the called bean whose transaction attributes are being configured, you can get yourself in a mess. Consider a bean with transaction attr Required. A session bean called from the client initiates a new transaction. This session bean is going to call these other beans (trans attr required), but if errors occur it wants to continue processing. However, since an error in the downstream bean throws an EJBException, this session bean no longer has a transaction context. To me, the deployer probably meant to configure that bean to not create transaction scope. I guess what I'm getting at is the deployer has to have pretty intimate knowledge of not only how each bean is supposed to work down to the code level, but how all the beans interact. This may be obvious, but in a complex system with lots of entities, there are a lot of calling relationships.
Can someone let me know if I'm off, or how I best deal with figuring out my configuration?
Thanks
Eric
