Hibernate version: any / none yet / current :-)
Code between sessionFactory.openSession() and session.close(): (yes, that's what I need to figure out... )
Name and version of the database you are using: MySQL 4 / Oracle

Hi everybody,

I've just started evaluating Hibernate, done some tutorials, read some documentation and everything seems to work just fine so far :-))).

However, I have one problem I couldn't find an answer to and I would guess I'm not the only one with this "issue"?!
I need to extend / refactor an existing server application, which currently uses a DAO pattern. I want to use Hibernate for all new entities, but need a way for it to "co-exist" with the current DAOs. Then, in due time and one by one, I hope I can convert the DAOs to Hibernate.
The main "issue" I see is one (JDBC-)transaction which is supposed to modify "Hibernate entities" as well as "old" "DAO-entities". How can I do this?


How do I do that? I could't find it in the documentation or the "code completion" for "session".
And is this the "proper" way of doing things? Will it work if I get a session, let Hibernate save a few objects, then execute 2 SQL statements via JDBC, let Hibernate update an Object (NOT the same classes, no association, each table will be accessed only by Hibernate OR DAOs).
I know this is not "perfect" and will only be needed for a "transition" period...

The documentation also says I can execute "plain SQL" statements and I couldn't find that either. I need to execute PreparedStatements from my code for entities which are not managed by Hibernate. Is that possible?

I've also started experimenting with a ConnectionProvider and actually got it to work very quickly (very good API *happy*). I could imagine a setup where my SessionFactory stores a JDBC connection along with the session in my ThreadLocal. When the session requests the connection, I see if I already have one for that thread (for the DAOs) and just pass the same connection. But how do I handle commit/rollback? I guess two commits are no problem, but what if Hibernate wants to commit and the DAOs want to roll back?

"Trying" all this in code would be a *LOT* of work (for me at least...), so I would really appreciate some hints from some Hibernate experts :-)))

Thanks in advance,

Holger

session.connection() gives you the corrent JDBC connection.

HTH
Ernst

Thanks! *lol* I must've been blind? ;-) I really DID look for it, I swear! *g* I guess I had assumed it must be "get.....()"

Well, whatever. I also saw that connection() will initialize a connection if it doesn't have one yet.

However, I'm still wondering about my other questions...


Of course the (very) simple "connection()" makes this look a LOT less like a "hack" *g* - but can there be any problems with "mixed access"? I'm very new to Hibernate (about 2-3 days? *g*) and don't quite know (yet) when it does its commits. I'm doing this in Tomcat (i.e. nonmanaged environment) for the near future, I guess that should reduce complexity.



I guess the answer is in the JavaDoc: "Applications are responsible for calling commit/rollback upon the connection before closing the Session."
So if I'm completely responsible for any commit/rollback, I guess there should be a way of avoding conflicts :-) However, I keep reading about Hibernate's smart write optimizations (lazy write?). Ho wdo I know when it's done? Can I assume that all "dirty" objects are written to the JDBC connection as soon as I've called "session.flush()"? Do I have to call flush if I want to roll back?

Finch

Hibernate never erver does a commit or rollback if you don't tell it to do so. You can have a look at the implementation of org.hibernate.transaction.JDBCTransaction. There's nothing fancy about the hibernate transaction handling.

In auto commit mode hibernate flush'es changes to the DB if there's a chance, that the memory and DB state of your instances could get out of sync. Up on calling commit on a Hibernate transaction, flush is called automatically.

HTH
Ernst