In plain Hibernate, what is the difference between SessionFactory.openSession() and SessionFactory.getCurrentSession(), and what determines the scope and lifetime of a "current" session?

## The problem being solved A persistence context should span exactly one unit of work, and every component in that unit of work should use the *same* one — otherwise two components loading the same row get two managed instances, dirty checking runs twice, and lazy references initialised in one component are unusable in the other. Passing the session down every call is explicit but noisy, so Hibernate offers an ambient lookup: `getCurrentSession()`. ## openSession ```java Session session = sessionFactory.openSession(); try { Transaction tx = session.beginTransaction(); ... tx.commit(); } finally { session.close(); } ``` Properties: always a new instance, never bound anywhere, never auto-closed, and it can be used without a transaction (reads only, in practice). Its correctness depends entirely on a `finally` block or try-with-resources — `Session` implements `AutoCloseable`. Missing `close()` is the number-one Hibernate resource leak: the persistence context stays reachable and the connection stays checked out of the pool, so under load the pool drains and the application appears to hang rather than fail. ## getCurrentSession and the context strategies `getCurrentSession()` asks a `CurrentSessionContext` implementation for 'the' session: **`thread` — ThreadLocalSessionContext.** A `ThreadLocal<Session>`. The first call on a thread opens a session, binds it, and registers a synchronization on the transaction. On commit the session is flushed and closed, then unbound; on rollback it is closed and unbound. Subsequent calls in the same thread and transaction return the identical instance, so calling code never closes it — doing so manually breaks the contract. **`jta` — JTASessionContext.** The session is bound to the current JTA transaction rather than the thread, which is the correct choice when a transaction can migrate between threads or when several resources are enlisted. **`managed` — ManagedSessionContext.** Hibernate does nothing on its own; an outer component calls `ManagedSessionContext.bind(session)` and `unbind(factory)`. This is what integration layers use when they want to control the boundary themselves — for instance opening the session at the start of a request and closing it at the end. You can also supply your own class name implementing `CurrentSessionContext`. ## Consequences worth stating in an interview 1. **A transaction is required** (for `thread`/`jta`). Calling `getCurrentSession()` with no transaction started throws `HibernateException: Could not obtain transaction-synchronized Session for current thread`. The session's lifetime is defined by the transaction, so there is nothing to bind it to otherwise. 2. **The thread is the boundary.** Handing work to an executor, a parallel stream, or an async callback moves it to a thread with a different (or no) bound session. Passing the session object into that thread is worse still — sessions are not thread-safe. Each task needs its own unit of work. 3. **Leaks are structural.** `ThreadLocal` binding on a pooled request thread means an unbound-but-not-closed session can outlive the request and be observed by the next task on that thread. Strategies that unbind on transaction completion avoid this; hand-rolled ThreadLocal caching of sessions does not. 4. **Flush on commit.** With the `thread` strategy, commit flushes and closes; you neither flush nor close manually. Code that calls `session.close()` on a current session breaks later components in the same transaction. ## Modern practice Hibernate 6 provides functional helpers that make the whole question mostly historical for new code: ```java sessionFactory.inTransaction(session -> { ... }); // void Order o = sessionFactory.fromTransaction(s -> s.find(Order.class, 1L)); ``` These open a session, begin a transaction, commit or roll back on exception, and close — the boundary is a lexical scope instead of an ambient one, which is easier to reason about and impossible to leak. When a managed environment already defines the unit of work, the `managed` context (or the container's own injection of an `EntityManager`) is the right integration point, and application code should simply receive the session rather than fetch it. A good senior answer names the strategy property, explains the transaction-scoped lifetime, and calls out thread-boundary and leak behaviour rather than reciting the two method names.