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 norma
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 us
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.openSubordinateSessio
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
session.connection() is completely useless in a JavaEE environment
@Resource Connection connection;
is much better
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
"subordinat
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
Hi,I have just started working on hibernate. I was trying to start with some sample applications.I am facing this problem when I am trying to insert data. It does not throw any error but does not do any insert.
I can easily fetch information using the same mapping.Can someone help me with this.I am
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
confi
http://forum.hibernate.org
/max
Hi,
I have just started working on hibernate. I was trying to start with some
sample applications.
I am facing this problem when I am trying to insert data. It does not
throw
any error but does not do any insert.
I can easily fetch information using the same
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
On Aug 30, 2006, at 9:39 PM, Steve Ebersole wrote:
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 tha
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 f
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 ca
Then we need @bad... ;)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Max Rydahl
Andersen
Sent: Wednesday, August 30, 2006 3:01 PM
To: Christian Bauer; hibernate-dev@lists.jboss.org
Subject: Re: [hibernate-dev] Connection proxying
>> The question was s
You should contribute to http://www.jcp.org/en/jsr/detail?id=305 ;-p
Steve Ebersole wrote:
Then we need @bad... ;)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Max Rydahl
Andersen
Sent: Wednesday, August 30, 2006 3:01 PM
To: Christian Bauer; hibernat
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/hibernate-hsqldb-testsuite?log=log20060830215954
TESTS FAILEDAnt Error Message: /home/cruisecontrol/work/scripts/build-hibernate-db-matrix.xml:92: The following error occurred while executing this line: /home/cruisecontrol/work/sc
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/hibernate-mysql-testsuite?log=log20060830232053
TESTS FAILEDAnt Error Message: /home/cruisecontrol/work/scripts/build-hibernate-db-matrix.xml:127: The following error occurred while executing this line: /home/cruisecontrol/work/sc
You should contribute to http://www.jcp.org/en/jsr/detail?id=305 ;-p
Steve Ebersole wrote:
Then we need @bad... ;)
:)
but seriously @deprecate is not only "a going away" marker.
From
http://java.sun.com/j2se/1.4.2/docs/guide/misc/deprecation/deprecation.html:
"Valid reasons for wishing
I would say .connection() falls in some of those categories and should
only be used in very few cases (until we provide alternatives for the
important "patterns").
Should have said:
...only be used in very few cases (and even less when/if we provide
alternatives
for the important "patt
19 matches
Mail list logo
