[hibernate-dev] Connection proxying

[Max Rydahl Andersen]

So I think we agree (just using different words ;)

Something like the Worker would be beneficial and s.getNewSession() might
be an alternative to sf.openSession( s.connection() ).

and session.connection() probably has to stick around as a necessary evil  
for some usecases.

When do you plan for Worker to be included ? 3.2.x ? 3.3 ?

Will it make sense to @deprecate session.connection() now for 3.2,  
documenting very explicitly
what alternatives there is etc.?

/max


> Depends... Do you mean the current session.connection()?  If so, then
> no, they will not be the same.  Currently, session.connection() enforces
> that the connection is usable until (1) the connection is "closed" or
> (2) the transaction ends.  If you tried the Work code you listed, that
> guarantee would not hold; the connection is only guaranteed to be valid
> during the performWork() call.
>
> No one is saying (at least I don't think so) that either of those cases
> is unimportant (I actually do not understand how your ConnectionProvider
> reference fits there though).  On the contrary, I specifically said we
> would need a plan for handling the sf.openSession( s.connection() ) case
> in my original e-mail.  The question was simply whether exposing the
> Work/command APIs justify removal of the connection() method from the
> perspective of using it for direct JDBC work.  I do not know that answer
> to that.  Unfortunately, I suspect it does not and that we will need to
> keep connection() around; but one can dream.
>
> -----Original Message-----
> From: Max Andersen
> Sent: Wednesday, August 30, 2006 12:08 PM
> To: Steve Ebersole
> Cc: hibernate-dev at lists.jboss.org
> Subject: Re: [hibernate-dev] Connection proxying
>
>
>> 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