This is onw of news of new hibernate version:

Deprecate the Session.connection() method, in favor of a "JDBC work" API. Schedule for removal in 4.0

So,
I used sometime this method of session object, now how i can replace it?

Thanks

I am also very interested in this, as I have some code that executes SQL directly... I simply use Hibernate to obtain my connections.

did you read the javadocs. it is first in 4.0 we will remove it.

Thank you Mr. Max,

i read the javadoc, "To be replaced with a SPI for performing work against the connection; scheduled for removal in 4.x "

but sorry i don't understand what does "replaced with a SPI for performing work against the connection" mean?

Could some one write me any code to show me how to replace the old code "sesssion.connection()" ?

Thank you all.

there is no direct replacement for this, but there will be in 4.0. Hence we added the deprecation warning now.

AHHHHHHHHHHH!!! ok.... thank a lot... sorry now i understand :)


but a simple question, why does Hibernate team want remove this api?
Is there any problem to use directly session.connecion() ??


Thanks

yes, as soon as you call .connection() we loose control over it an cannot anymore guarantee proper connection and/or tx management.

Hence we want to provide something like the following (note that this snippet is pure pseudo code not sure if this is going to be the api):



This allow us to control the lifecycle of the connection.

note, we are still pondering how we can still support the commonly used pattern of opening a session on the current session's connection...but I'm sure Steve is working on solving that :)

really.. good.....

good developer !!!!!

thanks a lot!!!

Just to clarify...

The new API will acctually start appearing in 3.3. Session.connection() will remain also, to be removed in 4.0. This gives people a chance to try and get used to the new API and gives us a chance to incorporate feedback before we actually remove Session.connection().

More than likely the API/SPI will come from parts of the work currently in the sandbox/jdbc

FWIW, I think it is improper to deprecate a method *before* providing a reasonable alternative. From the VM spec:

"A class, interface, method, or field may be marked using a Deprecated attribute to indicate that the class, interface, method, or field has been superseded."

http://java.sun.com/docs/books/jvms/sec ... html#78232

From java.sun.com documentation on "How and When To Deprecate APIs":

"A deprecated class or method is like that. It is no longer important. It is so unimportant, in fact, that you should no longer use it, since it has been superseded and may cease to exist in the future."

http://java.sun.com/javase/6/docs/techn ... ation.html

Emphasis here on "has been superseded".

From "The Java API Document Generator":

"Adds a comment indicating that this API should no longer be used (even though it may continue to work)."

http://java.sun.com/j2se/1.5.0/docs/too ... deprecated

-sullymandias

so you want us to not notify our users about the problem and surprise all users when 4.x comes out ? :)

I must admit I was a bit skittish myself when I saw this as we are using the raw connection in a few places, i.e. to enable tracing on the db side,etc which would fall under the umbrella of the JDBCAction semantics.

However, we are also using the raw connection to be able to spin off a fresh session piggybacked on the same connection/transaction. In some cases to look up data with different (or no) filters attached, etc.

Do you envision that will still be supported?

Max, precisely, you shouldn't notify users that something is deprecated if they don't have a fully working alternative that you are promoting. The right thing to do is implement your callback-style JDBCAction code in parallel with the session.connection() code in 3.3 or 4.0, allowing new users to choose the new callback-style code and allowing the old users backward-compatibility for the time being. Then in version 4.1, you can remove the session.connection() functionality.

Right now, everyone using Hibernate gets to see a deprecated warning message pop up in their build windows (and in their IDE), and we have no way to improve our code to get rid of that message. I don't feel like throwing a suppress-warnings annotation out there for the 100 or so places I'm using this code.

Connor

p.s. I didn't see the notification of the callback style in the latest API link from your website, so I had to Google around a bit before I stumbled upon this thread. Can you please document that this method is deprecated in the API for the future?

The session implements multiple interfaces, two of which provide the getConnection method signature. Only on, the Session interface, has the deprectaed warning applied. So you can remove the warning if you cast to the SessionImplementor interface. I am not saying this is the right approach, its just an approach. In anycase, please make sure you comment the change and when a workaround is introduced the code gets change to the new SPI.