[hibernate-issues] [Hibernate-JIRA] Closed: (HHH-1304) better handling of borrowed connections in non-ON_CLOSE release semantics

[Steve Ebersole (JIRA)]

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

Steve Ebersole closed HHH-1304.
-------------------------------


Closing stale resolved issues

> better handling of borrowed connections in non-ON_CLOSE release semantics
> -------------------------------------------------------------------------
>
>                 Key: HHH-1304
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1304
>             Project: Hibernate Core
>          Issue Type: Improvement
>          Components: core
>            Reporter: Steve Ebersole
>            Assignee: Steve Ebersole
>             Fix For: 3.1.1
>
>
> Currently, whenever a connection is borrowed via Session.connection(), a new connection (or handle) is returned in the case of aggressive-release.  It is then the responsibility of the borrower to close that connection after they are finished with it.  However, this is tedious since the behavior is different depending on the connection release mode being used.
> However, it is possible to have Hibernate handle this uniformly in any of the release-modes by proxying the connection returned from Session.connection() such that all requests on this borrowed connection are tunneled back into JDBCContext (as always, user-supplied connections are handled differently ;)
> I have this implemented and working locally.  The only remaining question is what the semantics of these proxies should be when the transaction associated to the JDBCContext to which the proxy is associated should be.  There are two likely possibilities:
> 1) Leave the proxy in a usable state with the express contract that subsequent invocations would occur in the new transaction (if one, or occur non-transactionally if not); potentially even on a new connection
> 2) Render the proxy unusable after said transaction completes.
> Currently #1 is chosen.

-- 
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