[hibernate-dev] Connection proxying

[Emmanuel Bernard]

session.connection() is completely useless in a JavaEE environment
@Resource Connection connection;
is much better

Max Rydahl Andersen wrote:
>
>> 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>