[hibernate-dev] Connection proxying

[Max Rydahl Andersen]

> However, removing that connection() method does additionally create an
> issue in regards to how to then deal with the common usage pattern of
> "subordinate sessions": sf.openSession( s.connection() )...  One thought
> was to add either a sf.openSubordinateSession( s ) or even
> s.openSubordinateSession()

and...
openSubordinateSession(Interceptor)
openSubordinateStatelessSession()

its a loong name...and isn't the session one gets from getSession a more  
true
"subordinate" ?

Needs a better name....or maybe just keep session.connection() around ? :)

What are the arguments *against* session.connection() if you do the  
proxying you
are suggesting ?

/max

> -----Original Message-----
> From: Max Andersen
> Sent: Wednesday, August 30, 2006 2:30 AM
> To: Steve Ebersole; hibernate-dev at lists.jboss.org
> Subject: Re: [hibernate-dev] Connection proxying
>
> Since the intention is to provide a safer execution for the user then
> +1,
> but if you are going to do this then i guess session.connection() will
> still be ok
> since it will just be proxied.
>
> btw. your example is a bit simplified since when hibernate runs inside
> an
> appserver
> the user will normally also have to cast through the appservers
> "proxying".
>
> ( ( OracleConnection ) (( AppServerConnection )  ( HibernateConnection )
>
> connection ).getWrappedConnection()
> ).getNativeConnection()).doSomethingOracleSpecific()
>
> ...but I guess we will then soon see NativeJdbcExtractorAdapter
> implementation for Hibernate ;)
>
> /max
>
>
>
>> This is in regards to the JDBC interaction code I recently committed
>> into the sandbox in SVN.
>>
>> I am considering proxying the JDBC connections specifically for the
>> purpose of auto-registering "subordinate objects" (result sets and
>> statements) for automatic cleanup.  Currently the registration is a
>> manual process in order to take advantage of the automatic cleanup
> (have
>> a look at org.hibernate.jdbc4.jdbc.impl.BasicWorkTest for the basic
>> usage pattern).  Specifically what I am thinking is taking a page from
>> how app servers implement Connection handles in relation to data
>> sources:
>>
>> public interface HibernateConnection extends java.sql.Connection {
>>     public Connection getWrappedConnection();
>> }
>>
>> Of course this makes it more difficult for anyone depending on casting
>> to a particular driver's Connection impl at some point.  But,
>> considering that this is atypical usage, my thought was to treat it as
>> the more complex use-case; and since this generally requires casting
>> anyway, one extra cast and "extraction" is not that big of a deal to
> me.
>> For example, to get an oracle connection (for LOB handling for
> example):
>> ( ( OracleConnection ) connection ).doSomethingOracleSpecific() -> ( (
>> OracleConnection ) ( ( HibernateConnection ) connection
>> ).getWrappedConnection() ).doSomethingOracleSpecific()
>>
>> Plus, would potentially allow for some other niceties like automatic
>> statement logging (perhaps even with parameter replacement).
>>
>> Thoughts?
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>



-- 
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
max at hibernate.org
http://hibernate.org

JBoss a division of Red Hat
max.andersen at jboss.com