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@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@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@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@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>>
>
>
>
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
[EMAIL PROTECTED]
http://hibernate.org
JBoss a division of Red Hat
[EMAIL PROTECTED]
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
