[hibernate-issues] [Hibernate-JIRA] Updated: (HHH-5184) Create a ConnectionAcquisitionMode as corollary to ConnectionReleaseMode

Steve Ebersole (JIRA) noreply at atlassian.com
Wed Jul 21 15:25:35 EDT 2010


     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steve Ebersole updated HHH-5184:
--------------------------------

    Fix Version/s:     (was: 3.6.0.Beta1)
                   4.x

> Create a ConnectionAcquisitionMode as corollary to ConnectionReleaseMode
> ------------------------------------------------------------------------
>
>                 Key: HHH-5184
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5184
>             Project: Hibernate Core
>          Issue Type: Improvement
>            Reporter: Steve Ebersole
>            Assignee: Steve Ebersole
>             Fix For: 4.x
>
>          Time Spent: 7m
>  Remaining Estimate: 0h
>
> 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:
> {code}
> 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...
>     }
> }
> {code}
> 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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the hibernate-issues mailing list