session.connection() is completely useless in a JavaEE environment
@Resource Connection connection;
is much better
and your point is ?
Tell me again how I get the connection injected into e.g. a Hibernate
interceptor ?
or in plain j2se etc. ;)
/max
Max Rydahl Andersen wrote:
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
_______________________________________________
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
