This is really only of interest to those of you using Hibernate via the "user supplied connection" approach; i.e. you call SessionFactory.openSession(Connection). And more specifically, those of you that use this approach in conjunction with "long running sessions".

The proposed change is to only accept these user supplied connections in openSession() and to no longer allow disconnect()/reconnect(Connection) sematics. This would align the usage pattern more with recent changes to the non user supplied connection approach.

Anyway, we are thinking of deprecating (and eventually removing) the corrolary methods on Session which allow "long sessions" to be used with this approach: Session.disconnect(), Session.reconnect(Connection), and Session.isConnected() methods. Disconnect/reconnect semantics are now implicit when not using user supplied connections, hence the desire to eventually remove these methods.

It should be noted that an alternative way to supply your own connections is a custom ConnectionProvider, in both cases of short or extended Sessions.

Hi, how can i vote?

We do use "user supplied connection".

Thanks

I put a time limit on the voting...

That's fine if you really want to use supplied connections. That's not what is being discussed here. What we are discussing is user-supplied connections in conjunction with the so-called "long running sessions" (i.e., using disconnect() and reconnect() between requests).

AFAICT this is already a decided issue; I have seen zero cases thus far where this is required considering the same functionality can be achieved by plugging in a custom ConnectionProvider in every case that I've seen.

I believe and it can be seen from the voting, that "User supplied Connections" is not a common approach and majority case suffices using the default....may I know what special circumstances warrant such apprroach as "User supplied Connections"?

What are some best practices / decision criteria for using User supplied connections vs Hibernate?

Can I have a credit? - the forum isnt sending emails out and I have a question as to why the goddam net.sf.ehcache.hibernate.EhCacheProvider library is not found with the jboss distribution.

Of course I would download it but the EhCacheProvider on sourceforge only as a .tgz extension which appears corrupted as I can only get 10-12 files out of it. Freaking unfriendly.

Speaking of unfriendly, did I mention how ANNOYING this credit system is.

Oh yes, I get it, please shut up unless you are helping. Well, I am not sure whose bright idea that was but it really goes against the grain of open source. Not to mention making the link the user forum greyed and unuser friendly to find. Is this Red Hat becoming a Microsoft issue or what?

Vent, vent, damn second level caching provider class not found, grrrrrrr.

double posting doesn't help...

bah delete it