Hibernate and transactions and table locking

If I have code that looks like the following:

beginTransaction();
// lots of stuff happens, can take anywhere from a minute to several minutes.
// it will read from several tables via calling getter methods on lazy relationships.
commitTransaction();

In between the begin and commit, are the tables that are being read from being locked and subsequently will 开发者_StackOverflowthis cause problems in a multi-user environment where issues will occur when the same code above is called by another user?

If the above is problematic, should we always try and keep transactions short? and to facilitate this, instead of calling getter methods on lazy relationships, does that mean its best to keep the transactions short and do finds manually for the children of the parents?

---

Hibernate is not going to do anything to explicitly lock tables you read from. The answer really depends on what Database you're using and what your isolation levels are set to. Locking an entire table by reading rows shouldn't happen in any full featured database written in this century. For any multiversioning database, nothing is going to get locked unless you explicitly lock the row yourself.

Your transactions should be whatever length they need to be for your atomic unit of work. There's no right or wrong length. Ask yourself "does everything that happens here succeed or fail as a single unit and all get rolledback together if any one piece fails?" That's the scope you set a transaction for.

Remember, you do not need a transaction to have lazy loading! You just need an open Session. The two are not linked. You can commit your transaction and keep your session open to keep lazy loading working.

---

The best thing is to keep transactions short. The locking semantics depends on the transaction isolation levels though.

Open Session In View is the pattern your are looking for when you are talking about lazy-fetching/relationships.