What's the official way to do this?

I'm using the following code to configure Hibernate:


From there hibernate just deals with all the JDBC crap and everything goes along just swimmingly.
But now I have to get my hands dirty with a direct JDBC connection.
Given this configuration setup, what's the best way to get a direct JDBC connection?
I figure the best thing to do is get the ConnectionProvider Hibernate is using, because (a) it seems obvious and (b) one day I'm going to need to get the ConnectionProvider in order to register a Proxool lifecycle listener.

I can do dodgy things like:

Cast SessionFactory to SessionFactoryImplementor and then call getConnectionProvider() (this is how our app does it currently, but it makes me feel dirty so I want to find a Better Way).

Register our Custom ConnectionProvider subclass with a singleton and then call that to get connections.

But how am I supposed to do this?
I don't particularly want to create/close a session just to use it's connection, or is that "the" way to do it?

Either, session.connection()
Or give Hibernate a userConnection and manage it yourself.

So you think it's OK to cast SessionFactory to SessionFactoryImplementor?
Same for other classes, like casting Session to SessionImpl?

I route all my dataaccess through hibernate- that is, if I need to do something in jdbc, I retrieve the connection via session.connection().

Using the hibernate config (xml) files to move from local jdbc connection in test/unit testing, and changing to a jndi source is very simple.

No problems so far, although keep in mind that you autocommit may not default to "on" when you get a connection this way.

James

I don't see the need for the cast. Session declares:


This is on Session, not SessionFactory. SessionFactory, as its name implies, will give you the session. You may want to look at the ThreadLocal pattern if you haven't already, it gives a good, simple, implementation for managing sessions (and hence connections).

http://www.hibernate.org/42.html

Our application currently does the implementor casting in order to get the ConnectionProvider so that it can create new JDBC connections.

So it seems like the consensus is that when you want to use a JDBC connection directly, the correct way to do it is to get a brand new Hibernate Session, use it's connection, then clean up the Hibernate Session (as opposed to trying to get Connection objects from the ConnectionProvider)?

Never cast on internal Hibernate API.

I'd recommend using an Inversion-of-control (aka, Dependency Injection) framework such as Spring for this. Let it set up the DataSource and supply it to whatever needs it: Hibernate or your own JDBC logic.

That's what I'd say is a "correct" approach.