Hello!
I have some newbie questions regarding the Session and Transaction.

- Why is the Session-per-operation considered an anti-pattern. Is it because the Session creates a new connection to the db for every new Session that is created?

- Does the call means that rows/tables are locked in the db until a commit() or rollback(). If another thread in the application tries to read the same rows/tables at the same time and isolation-level is set to READ COMITTED, the second thread must wait until the first thread has done tx.comit() or tx.rollback()?

Regards
/Fredrik

In my opinion it is because as soon as you want to combine several operations into a new operation you are stuck. If you want the new operation to happen in a single transaction, the existing operations can't be re-used. And if the code can't be re-used, it means you have to copy-and-paste relevant parts of the code into the new operation and in the long term to problems maintaining the code.



No. As a general rule rows are locked when a transaction is trying to update them. But, this is not always so simple, database implementation usually have a lots of "tricks" to reduce locking time, increase performance, read-lock/write-lock etc. You'll need to check the documentation for the database you are using to understand the limitations and features that exists in that particular implementation.



I only have experience with MySQL (with InnoDb tables) and PostgreSQL. For those two the answer is no. The second thread will only see what has been committed to the database. Non-committed changes are invisible to the seconds thread. Eg. newly inserted rows will not be returned by queries, deleted rows are still visible, modified rows have their old values, etc.