[hibernate-dev] Connection proxying

[Max Rydahl Andersen]

> Session s = ...;
> Connection c = s.connection();
> PS stmnt = c.prepareStatement( ... );
> RS rs = stmnt.executeQuery();
> s.load( ... );
> rs.next();
> ...
>
> Seems harmless enough, right?  Will it work?  Answer: well it depends ;)
> Both the ConnectionProvider being used and the connection release mode
> configured play parts in this (which is a PIA to explain and even more
> so to justify).  This is exactly the scenario which forced me to add the
> notion of BorrowedConnectionProxy to the core as it is now in the first
> place, so that the behavior could be consistent; the downside is that it
> essentially overrides *any* connection releasing.

ah yes - it comes down to the release mode. Now I remember.

so should we start by @deprecate connection() in 3.2 ?

We don't really have any other portable way of exposing the connection  
running the same tx as the session.

> If you as a user are doing some work with the connection obtained from a
> Hibernate Session, how big of a disruption is it to change from that
> usage pattern to this new usage pattern.  And whether than disruption is
> then adequately offset by any advantages of this new usage pattern.

Yes, and for the usecase of simply getting a connection and do a "one-off"  
task
the change is not a big deal.

The issue comes when you are in the scenario of having mixed Hibernate and  
JDBC code;
here getting access to a shared connection is good (session.connection()  
is one, openSession(connection) is another and ConnectionProvider is a  
third)

But I would argue all three are relevant, but I would also be completely  
fine
by giving those who want to have "unbounded" access a bigger burden ..e.g.  
remembering to close the connection,
live with releasemode being circumvented etc.

> The advantages are the typical "avoid tedious error handling", "avoid
> redundant resource management", blah-blah-blah you heard from every
> other library supporting delegation/templating solutions to JDBC access.
> Additionally, you get integration with our notion of connection release
> modes, exception conversion, logging, etc.  Some of those "extras" could
> be achieved even via exposing the proxy rather than the "raw"
> connection, but the connection release modes are explicitly
> circumvented...

I don't talk against having the new thing exposed, fine by me.

I just think there still is a important "niche" usage for  
session.connection(). (not forgetting many books, training, examples,  
applications that refers to this method)

On that note:

Will the following snippet be equal to c = session.connection() ?

final Connection[] c = new Connection[1];

session.doWork(
     new Work() {
         public void performWork(Workspace workspace) {
             c[0] = workspace.getConnection();
         }
     }
);


/max

>
> -----Original Message-----
> From: Max Andersen
> Sent: Wednesday, August 30, 2006 9:09 AM
> To: Steve Ebersole
> Cc: hibernate-dev at lists.jboss.org
> Subject: Re: [hibernate-dev] Connection proxying
>
>
>> 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