Not sure. You know I would love to get rid of Session.connection()
completely. Guess it depends on how clean and generally useful this new
Work and command code becomes.
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()
-----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
