Ouch !!
Well, the EJB 2.0 spec is *very* specific on the fact that EJBs do NOT support nested transactions. Moreover, it also states that the resource manager specific transaction demarcation methods (such as Connection.commit() for JDBC) must not be used while in an existing bean-managed transaction (17.3.3).
However, the spec (17.1.1) lets some room for future implementations:
Many applications will consist of one or several enterprise beans that all use a single resource manager (typically a relational database management system). The EJB Container can make use of resource manager local transactions as an optimization technique for enterprise beans for which distributed transactions are not needed. A resource manager local transaction does not involve control or coordination by an external transaction manager. The container�s use of local transactions as an optimization technique for enterprise beans with either container-managed transaction demarcation or bean-managed transaction demarcation is not visible to the enterprise beans. For a discussion of the use of resource manager local transactions as a container optimization strategy, refer to [ 9 ] and [ 12 ].
However, if one does not use JTA at all and goes with JDBC transaction manager then it is possible to use nested transactions in BMT sb This is correct, but your beans will not be the best example of portability!
Note that 24.2.5 (JDBC 2.0 extension requirements) states that:
The EJB Container must include the JDBC 2.0 extension and provide its functionality to the enterprise bean instances, with the exception of the low-level XA and connection pooling interfaces. These low-level interfaces are intended for integration of a JDBC driver with an application server, not for direct use by enterprise beans.
[ October 19, 2004: Message edited by: Valentin Crettaz ]