Hibernate version:
3.1b<LATEST>
Full stack trace of any exception that occurs:
Exception "Transaction was not properly started"
Name and version of the database you are using:
MySQL
Question
What is a valid strategy to commit/rollback transaction if I'm using "Open session in View" pattern.
Currently I'm doing following:
1. Before execution of the business code open a session and open transaction
2. After execution of the business code check that no runtime exception occur and commit transaction. But do not close session because session will be needed for the view (lazy load).
3. After view proceeded, rollback the transaction.

With latest hibernate 3.1 I've got "Transaction was not started" exception on the step 3. This seems to be a new feature that was added in the latest beta. How do you think, what is the most proper way to handle the situation:
1. After commiting transaction first time (after business objects execution) opoen another transaction and rollback it afterwards.
2. Do not open transaction second time and do not rollback it either.

Thank you.

Renat Zubairov

You do not need a Transaction to load Objects. So if your view does not change the Objects (views should not do that), you do not need a Transaction.

Wrong! Please don't give people bad advice and repeat the usual auto-commit mode confusion. All communication with a database occurs inside a transaction. Using auto-commit mode and many small transactions, one for each statement, is a very bad idea.

I would never use auto-commit mode!

But if you only read from the database and don't change the persistent objects, I think there is no use to call session.beginTransaction(). I always wondered why the Hibernate-examples, that only read from the Database, call session.beginTransaction(). So where is the difference? These examples, run well without calling session.beginTransaction().

I know, that every select needs a database-connection, and that every database-transaction belongs to a database-connection. But I think, it is not necessary to commit or rollback, if you only read from the database. So you don't need a Hibernate-Transaction. The session encapsulates a Database-Connection (if not disconnected) so Select-Queries work fine without calling session.beginTransaction().

Am I wrong?

There is no such thing as No Transaction.

The examples run because beginTransaction() is not needed in a non-managed environment, as setting auto-commit to false, when obtaining a connection, implicitly starts a transaction. The same code won't run anywhere else.

Of course it is necessary to commit or rollback if you read from a database. What else should happen? There is no third state or option. If you don't do it yourself you get UNDEFINED (or at best documented DEFAULT) behavior. That's not what you want and you should not recommend it.

But it still do not clear. For the transaction that happened during the view rendering (Open session in View) which action should I do at the end? Should I commit it or rollback? I.E. is it possible that Hibernate will do some modification inside the database during resolution of the lazy associations?

Why would you ever rollback if no problem occured (except in integration testing, maybe)? A regular transaction begins and commits.

Transaction must be defined (demarcated by "begin" and "end") to read correct data, it transaction is undefined then data returned from query is undefined too (you will get stale data this way in serializable isolation level).

This is wrong, 3 can read wrong data if yor transaction is demarcated as "request". Correct is the simplest way: begin, commit transaction (rollback on exception) and close session ( request = transaction ).