I'm reading the reference documentation for Hibernate 2.1.1 and have a concern regarding the "Worked Example" in chapter 11.3. In the example, transactions are used even for read only operations, such as the listAllBlogNamesAndItemCounts() and getBlogAndAllItems() methods.

Why is that?

Why do you think you don't need transaction demarcation for read only operations?

P.S. Search the forum, has been asked a dozen times before.

Thanks for the very prompt reply!



There is only a single query involved and I figured they are atomic any way. Aren't they???

We have the isolation level set to serializable, and I want to avoid transactions for (some slow) read only operations to avoid deadlocks. Is this discouraged with Hibernate?

Since the reference manual also reads

I'm puzzled what would be the normal way to solve this.




I feel really stupid but I'm not able to find anything useful. All I found is somebody else getting the same reply. Would you be kind enough to point me somewhere?

If this is such a frequently asked question, maybe this should be adressed specifically in the documentation?

hi mate,
this is not related to hibernate.
Everything you do on your database needs a transaction no matter if it is hidden or not.
Autocommit for example is a kind of hidden transaction management and it is not a good thing.

Google may help you to have all the story about read only also needs a transaction

How can you "avoid" transactions on a JDBC connection? Communication always occurs in a transaction, no matter if you explicitely declare it with whatever API (the Transaction Hibernate API is a good choice, usually) you like or let the auto-commit mode do the work. Of course, auto-commit itself is not a useful mode for OLTP applications.

I know that, but for single SQL statements (whether updating or read only) an autocommit would have the exact same effect as an explicit transaction. I have never before encountered the need to have explicit transaction demarcation for single database queries, therefore I do believe it is related to Hibernate (and a Google wouldn't do much good).

Yes, but what point is there to use explicit transaction demarcation (as opposed to auto commit) around single, read only queries?

And how would I avoid deadlocks for multiple/time consuming read only queries? (Having a single explicit transaction around every single query? I don't think so...)

you can easily understand that hibernate cannot let autocommit = true because the session need to do a lot of things and need your demarcation.
How can the core know you are doing a simple atomic query? after this the persistent objects returned by the query need to be watched by the session inside a transaction...
You can try some helper class to switch to autocommit = true when you want, but this is absolutely not good and i don't really know if this will work

Sorry, no I can't. That was my original question.
Is the explicit transaction needed to include "behind the scenes" queries in the same transaction as the actual query?



Does it need to? Why?
If I decide "this operation does not need to lock any records", can't Hibernate trust me to know what I'm doing.

And still, the question remains: how would I go about NOT to lock, when MySQL implicitly locks everything read in serializable mode?

download sources and take a look at how hibernate works, if saying
"the session needs to do a lot (for example dirty checking and initializing proxy and much more)" is not enough for you, please trust me i have no time to explain you all the stuff and you can see in the sources how it works.

Ok, but if Hibernate requires a transaction, why isn't one started implicitly when a session is opened, and commited implicitly when the sessions is closed? It seems what your're saying theese two always appear in pairs anyway (except for rollbacks and commit/begin of multiple transactions inside single session; if that is supported, that is)?

Dirty checks aren't needed for read only operations, are they? And I can't see any proxies being used in the example. So it seems I have misunderstood some fundamental principles of Hibernate, and maybe migrating to it isn't a very good idea after all...

of course this is not recommended and extremely dangerous!


you can do what you want ;)

hibernate is not only an object oriented query language.
hibernate is not only a persistence engine.

Be sure i'm friendly and this is a real advice: read HIA, it talks about orm in general.

You're getting nervous because of one particular use case that is problematic with mySQL, maybe the problem is elsewhere...

Is it really hard for you to
- use transaction api and call begin and commit ?
- write this use case in pure jdbc to use this very extraordinary feature that is autocommit? hum hum

just an advice, querying can be reused elsewhere in your app, so it's a best practice to isolate queries.
If so, how to know when the returned objects will be read or updated?
The transactions (db or applicative) have to be managed by the layer calling the queries.
Typically, controller calls DAO, so maybe controller have to_know_ about transaction....

Your problem is definitly a design problem.

There is no difference between an auto-committed serializable JDBC connection and an explicitely committed serializable JDBC connection, for each query respectively. You get nothing from serializable in this case. Is serializable the default mode for all your JDBC connections? That would be a special case, and not common.

It's a matter of declaring transaction boundaries or not and here we only have experience to judge: I think setting transaction demarcation explicitely (no matter if its done in Java code or in deployment declarations, Annotations, etc. ) is good practice. Making an exception for read only queries for no particular reason is bad practice.

Because there are times when a Session is not the same scope as a database transaction. As Anthony said, this is a question of application design (something we call long Application Transactions). Read up in Hibernate in Action, the JavaPolis conference slides (I have to link that...) also have some diagrams.

Well. We've had problems with deadlocks so I just spent about three weeks implementing AOP transactions and wading through 200'000+ LOC setting (serializable) transactions only for updating operations.

If moving to Hibernate means this work will be undone, it's probably less interesting - at least for my boss...



Really? Then this might be the root of the problem.
Maybe I should use a lower transaction isolation level for all read only operations, and increase to serializable for updating transactions? (Is it possible to increase isolation level in the middle of a transaction?)

Back to planning in that case.
I know how the different isolation levels affect that database, but can I read about the JDBC/Hibernate aspect of it somewhere?