My understanding is that first style (get connections first, then begin a
transaction) must be supported by the EJB container. The EJB spec (11.3.3)
uses this style in the example that demonstrates bean managed transactions.
Its actually a reasonable coding approach as it moves the potentially time
consuming connection management outside the scope of the transaction.
One problem in supporting this is that there is no standard API to do the
delayed enlistment of connections to the transaction - neither JTA nor
JDBC addresses the interfaces necessary to allow this to occur. So as it
is, each container must roll its own with regard to this (container jdbc
dataSource implementation squirrels away connections so that the container
JTA implementation can enlist them at tx.begin(). This works against the
pluggability of JTA implementations into EJB containers, but that's the way
it is.
BTW, just using thread state to hold the connections for delayed enlistment
isn't good enough since you have to assume that a connection acquired in a
previous method invocation (possibly on another thread) and held in an
instance variable may also be used within a transaction.
Alan
>
> One thing to be wary of that I've seen is the following:
> Connection con = dataSource.getConnection();
> tx.begin();
> ...
> tx.commit();
> con.close();
>
> which should be in this order instead (to allow correct tx management of
> connections:
> tx.begin();
> Connection con = dataSource.getConnection();
> ...
> con.close();
> tx.commit();
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
