We're updating the issue view to help you get more done. 

Create a ConnectionAcquisitionMode as corollary to ConnectionReleaseMode

Description

Originally ConnectionReleaseMode was added to work around a particular problem of connection "leaking" by JTA containers when used in situations of nested session EJB calls. The connection was not really leaked, but it would appear that way to the JTA resource tracker.

The situation was:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 class EJB1 { public void doSomething() { Session s = getCurrentSession(); ... ejb2.doSomethingElse(); // now use the HIbernate session } } class EJB2 { public void doSomethingElse() { Session s = getCurrentSession(); // Use the session in a way that requires a Connection... } }

What happens is that EJB1 obtains a Session reference. Just getting a Hibernate Session does not make it get a Connection; the Session delays getting a Connection until it actually needs one. EJB1 then makes the call into EJB2. Again, EJB2 obtains the same Session reference and does some work, so the Session obtains a Connection. Historically that Connection would be held until the Session closed. However that was problematic in this scenario above; to the JTA container it looks like EJB2.doSomethingElse() is leaking the connection outside the transaction boundary (this was many years ago and AFAIU many of these JTA scoping routines have become more sophisticated).

At the time we decided to add the idea of Connection "releasing". However constantly releasing and re-obtaining the Connection can affect performance. Another solution to the problem above is to obtain the Connection up front instead.

So initially I see:
ConnectionAcquisitionMode.AS_NEEDED
ConnectionAcquisitionMode.IMMEDIATELY

Environment

None

Status

Assignee

Steve Ebersole

Reporter

Steve Ebersole

Fix versions

Priority

Major