Hello

1) Is it necessary to "load" an object inside a transaction?



What are the implications if a beginTransaction and commit are omitted?

2) If a HibernateException occurs at the load stage:

a) is it necessary to rollback the transaction?

b) why would you rollback a SELECT statement?

Thanks

Mark

1. All data access (read/write) works inside a hibernate transaction for an active session. So I dont think your load will work if you dont put it inside transaction.

2. You would usually write your beginTransaction and commit/rollback in a centralized place. When there is no exception commit would happen and if there is an exception which needs rollback then you would rollback the transaction. These part of your code would usually be not aware of what you do inside that transaction. In the example that you have shown there is a single select statment, but that wont be true for a generic transaction. Also there could be some other cleanup code which might be performed by hibernate when you call rollback().

In many cases, you can get by without using a transaction. In fact, lot of our lazy loading happens outside Hibernate transactions - you would have to know _when_ your lazy loads happen to write a transaction around them - that would break DAO encapsulation all over the place.

One of the reasons why you DO need a transaction has everything to do with the fact that Hibernate is a Session persistency engine, not just another JDBC layer:
Your session may contain object(s) which have been changed (by your application). At the time of the object LOAD, Hibernate may have to assure that it will be loading the 'right' data - which may be affected by your not-yet-commited changes in your session.

In case where your query is simply by ID, Hibernate can do all necessary checking, easily, by inspecting session cache (organized by object identity). But in case your load uses a more complex selection query, Hibernate would have to 'understand' what is the relationship of your session data changes to the select 'where' clause.

Since Hibrnate does not pretend to be an SQL engine, in case of such a load query, it will first synchronize your database with your session state = it will flush() all your changes to the database. Only then it will perform your select query. And the flush() performed here needs a transaction - in fact, you may have to rollback and/or handle error conditions such as a deadlock - even though you 'think' that you are making 'just a select'...

The lazy loads mentioned above do not (normally) flush(), simply because they (as far as I know) load objects by their identity, and Hibernate can check the session for any such objects (potentially already loaded, cached and changed by other session operations) by their identity.

To make the whole story short, you simply get used to transacting your loads. Remeber, you are NOT transactioning single object changes, you are transactioning your entire Session changes (and sometimes you may be surprized what your load and/or commit flushes out).

{don't forget to rate if this helped}
Martin.