A Hibernate Session is just a transactional write-behind cache that translate entity state transitionsinto 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:

  • session-per-request (the session is bound to the life-cycle of a single logical @Transaction and one physical database transaction)
  • long conversation (the session can span to multiple @Transaction operations, hence there are multiple database transactions involved)

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 releasedafter each statement, but it practice you still get the same JDBC Connection handle within the context of a single logical transaction.

Now back to your questions:

  1. 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.

  1. 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.

  1. From Hibernate Documentation, earlier versions of Hibernate required explicit disconnection and reconnection of a Session. These methods are deprecated, as beginning and ending a transaction has 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.

source - https://stackoverflow.com/questions/28486850/what-is-the-difference-between-a-session-and-a-connection-in-hibernate

Hibernate Architecture

In the Hibernate we found the many of object like persistent object, session factory, transaction factory, connection factory, session, transaction all are include in the hibernate architecture.

In the Hibernate architecture we sees that it is a layer to keep you isolated from having to know the underlying APIs. Hibernate makes use of the database and configuration data to provide persistence services (and persistent objects) to the application.

There are 4 layers in hibernate architecture java application layer, hibernate framework layer, backhand api layer and database layer. Let's see the diagram of hibernate architecture:

This is the high level architecture of Hibernate with mapping file and configuration file.

Hibernate framework uses many objects session factory, session, transaction etc. alongwith existing Java API such as JDBC (Java Database Connectivity), JTA (Java Transaction API) and JNDI (Java Naming Directory Interface).

Elements of Hibernate Architecture

For creating the first hibernate application, we must know the elements of Hibernate architecture. They are as follows:

Session Factory

The SessionFactory is a factory of session and client of ConnectionProvider. It holds second level cache (optional) of data. The org.hibernate.SessionFactory interface provides factory method to get the object of Session.


The session object provides an interface between the application and data stored in the database. It is a short-lived object and wraps the JDBC connection. It is factory of Transaction, Query and Criteria. It holds a first-level cache (mandatory) of data. The org.hibernate.Session interface provides methods to insert, update and delete the object. It also provides factory methods for Transaction, Query and Criteria.


The transaction object specifies the atomic unit of work. It is optional. The org.hibernate.Transaction interface provides methods for transaction management.


It is a factory of JDBC connections. It abstracts the application from DriverManager or DataSource. It is optional.


It is a factory of Transaction. It is optional.

source - http://r4r.co.in/java/hibernate/hibernate_tutorial/hibernate_architecture.shtml


Sessions are a key component of the Oracle Application Server TopLink application--they provide OracleAS TopLink with access to the database. Sessions enable you to execute queries, and they return persistent objects and other results for client applications. This chapter introduces OracleAS TopLink sessions, and describes:

Introduction to Session Concepts

A session represents the connection between an application and the relational database that stores its persistent objects. OracleAS TopLink provides different session classes, each optimized for different design requirements and data access strategies. OracleAS TopLink session types range from a simple database session that gives one user one connection to the database, to the session broker that provides access to several databases for multiple clients.

To understand the OracleAS TopLink session, you must be familiar with several session concepts.

sessions.xml File

In most cases, the developer pre configures sessions for the application in a session configuration file. This file, known as the sessions.xml file, is an Extensible Markup Language (XML) file that contains all sessions that are associated with the application. The sessions.xml file can contain any number of sessions and session types.

Session Types

Several session types each provide a particular set of functionality to the application.

Server Session

A server session is the most common OracleAS TopLink session type, because it supports the three-tier architectures that are common to enterprise applications. Server sessions manage the server side of client-server communications. They work together with the client session to provide complete client-server communication.

The server session provides shared resources to a multithreaded environment, including a shared cache and connection pools. The server session also provides transaction isolation.

For more information about the server session, see "Server Session and Client Session".

Client Session

A client session is a client-side communications mechanism that works together with the server session to provide the client-server connection. Each client session serves one client.

For more information about the client session, see "Server Session and Client Session".

Remote Session

A remote session offers database access to clients that do not reside on the OracleAS TopLink Java virtual machine (JVM). The remote session connects to a client session, which, in turn, connects to the server session.

For more information, see "Remote Session".

Database Session

A database session is a unique session type because it provides both client and server communications. It is a relatively simple session type that supports only a single client and a single database connection. The database session is not scalable; however, if you have an application with a single client that requires only one database connection, the database session is usually your best choice.

For more information, see "Database Session".

Session Broker

The OracleAS TopLink session broker is a mechanism that enables client applications to communicate with multiple databases. A session broker makes multiple database access transparent to the client.

For more information, see "Session Broker".

source - https://docs.oracle.com/cd/B10463_01/web.904/b10313/sessions.htm

Oracle Application Server TopLink Application Developer's Guide

common concepts that get used with SQL Server thread management and scheduling

Sessions – when the client application connects to SQL Server the two sides establish a “session” on which to exchange information. Strictly speaking a session is not the same as the underlying physical connection, it is a SQL Server logical representation of a connection. But for practical purposes, you can think of this as being a connection (session =~ connection). See sys.dm_exec_sessions. This is the old SPID that existed in SQL Server 2000 and earlier. You may sometimes notice a single session repeating multiple times in a DMV output. This happens because of parallel queries. A parallel query uses the same session to communicate with the client, but on the SQL Server side multiple worker (threads) are assigned to service this request. So if you see multiple rows with the same session ID, know that the query request is being serviced by multiple threads.

Connections – this is the actual physical connection established at the lower protocol level with all of its characteristics sys.dm_exec_connections . There is a 1:1 mapping between a Session and a Connection.

Literally : Connection is Physical Communication Channel and Session is a state of information exchange. A Connection may have multiple sessions.

The connection is the physical communication channel between SQL Server and the application: the TCP socket, the named pipe, the shared memory region. The session in SQL Server corresponds to the Wikipedia definition of a session: a semi-permanent container of state for an information exchange. In other words the sessions stores settings like cache of your login information, current transaction isolation level, session level SET values etc etc.

Normally there is one session on each connection, but there could be multiple session on a single connection (Multiple Active Result Sets, MARS) and there are sessions that have no connection (SSB activated proceduressystem sessions). There are also connections w/o sessions, namely connections used for non-TDS purposes, like database mirroring sys.dm_db_mirroring_connections or Service Broker connections sys.dm_broker_connections.

I got the reference from here

source - https://stackoverflow.com/questions/39199173/difference-between-session-and-connection-in-sql-server

'DB > Common' 카테고리의 다른 글

Transactoin Isolation Level  (0) 2019.02.16
SQL - Session, Connection  (0) 2019.02.16
sql - sql by wiki  (0) 2015.12.14
search - Elasticsearch  (0) 2014.04.24
db - jdbc vs jpa  (0) 2013.09.14
db - ACID  (0) 2013.06.22
Posted by linuxism