Menu
I want to clear the basic 3 points,
Does beginning a new database transaction on an old session obtains a new connection and resumes the session?
Does committing a database transaction disconnects a session from the JDBC connection and returns the connection to the pool?
From Hibernate Documentation, earlier versions of Hibernate required explicit disconnection and reconnection of a Session. These methods are deprecated, asbeginning and ending a transaction has the same effect. How do they have the same effect?
302
Connection is the relationship between a client and a SQL Server database. Session is the period of time between a client logging in (connecting to) a SQL Server database and the client logging out (exiting) the SQL Server database.
The Session interface is the main tool used to communicate with Hibernate. It provides an API enabling us to create, read, update, and delete persistent objects. The session has a simple lifecycle. We open it, perform some operations, and then close it.
SessionFactory is a factory class for Session objects. It is available for the whole application while a Session is only available for particular transaction. Session is short-lived while SessionFactory objects are long-lived. SessionFactory provides a second level cache and Session provides a first level cache.
A session is what you use to interact with the database. A transaction is used to specify boundaries for the session to operate within. Essentially, transactions prevent the database from being corrupted by only allowing a session to interact with it at one time.
A Hibernate Session is just a transactional write-behind cache that translates entity state transitions into DML statements. The Hibernate Session can be connected or disconnected from the database. When it is disconnected, it cannot flush current pending entity state changes to the underlying database.
There are multiple ways to associate a Hibernate Session to a database transaction:
When it comes to database transactions, there are two different approaches:
RESOURCE_LOCAL transactions, using a single DataSource will always bind a physical database transaction to a Hibernate Session (within the context of a single logical transaction, meaning that you can still implement long conversations to span over multiple such logical transactions).
JTA, using multiple DataSources. JTA state that connections should be aggressively released after each statement, but in practice, you still get the same JDBC Connection handle within the context of a single logical transaction.
Now back to your questions:
- Does beginning a new database transaction on an old session obtains a new connection and resumes the session?
Yes. The Hibernate session is reconnected and flushing/committing can proceed.
- Does committing a database transaction disconnects a session from the JDBC connection and returns the connection to the pool?
By default, when you commit a transaction, the Session is closed and the underlying connection is closed. If you use connection pooling, the database connection will indeed return to the pool.
- From Hibernate Documentation, earlier versions of Hibernate required explicit disconnection and reconnection of a Session. These methods are deprecated, as the beginning and ending of a transaction have the same effect. How do they have the same effect?
These methods are deprecated because the connection management is now controlled by the connection release modes.
133
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
