[hibernate-dev] Connection proxying

[Steve Ebersole]

Imagine this usage:

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.  

But, regardless, I do not like exposing the connection for "unbounded"
use.  It leads to too many quirks and difficulties like the one
mentioned above.  I think it really comes down to the answer to this
question:

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.

And to be clear, what I am talking about is along the lines of...
Old:
Connection c = session.connection();
try {
    // do work with the connection
}
catch( SQLException sqle ) {
    ...
}
finally {
    c.close();
}

New:
session.doWork(
    new Work() {
        public void performWork(Workspace workspace) {
            Connection c = workspace.getConnection();
            // do work with the connection
        }
    }
);

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


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