What is Hibernate's StatelessSession, and which capabilities of the regular Session do you give up when you use it?

## What it is Hibernate's `StatelessSession` is a second, deliberately minimal API onto the same `SessionFactory`, the same mappings, and the same JDBC connection handling. You open it with `sessionFactory.openStatelessSession()`. It exposes `insert(Object)`, `update(Object)`, `delete(Object)`, `get(Class, id)`, `refresh(Object)`, and full query support (HQL, native SQL, Criteria). The defining property is in the name: **there is no persistence context**. A regular `Session` is stateful — it remembers every entity it has loaded or persisted, guarantees object identity per row, tracks changes, and defers SQL until flush. A `StatelessSession` remembers nothing between calls. Each method is a command that maps more or less directly onto a SQL statement. ## Everything you give up, and what each loss means **The first-level cache and identity map.** In a `Session`, `get(Order.class, 1L)` twice returns the same instance; repeat loads of the same row cost nothing after the first. In a `StatelessSession` each `get()` runs a SELECT and returns a fresh, **detached** object. Two loads of the same row give you two unequal-by-reference objects, so any code relying on `==` identity, or on `equals()` implemented by identity, breaks. The upside is that memory does not grow with the number of rows touched: nothing is retained, so a loop over ten million rows needs no `clear()`. **Automatic dirty checking.** There is no loaded-state snapshot, so nothing detects your mutations. Changing a field on a loaded object writes nothing. You must call `update(entity)` explicitly — and because there is no snapshot to diff against, the generated UPDATE sets **all** mapped columns, not just the changed ones. **Transactional write-behind.** A `Session` queues actions and orders them at flush time. A stateless session issues its statement at the call site instead. (Modern Hibernate 6 can still group these into JDBC batches when batching is configured; historically each call was its own round trip.) This makes ordering entirely your problem: if a child row references a parent, you must insert the parent first. **Cascades and collections.** Cascade settings are ignored, and collections are not managed at all. Inserting a parent does not insert its children no matter what `CascadeType` you declared. You write each row yourself and set the foreign keys yourself. **Lazy loading.** With no session-attached proxies to initialize, you cannot rely on navigating lazy associations off a stateless result. Fetch what you need with an explicit `join fetch` in the query, or load it as a separate query. **Events, interceptors, and callbacks.** Stateless operations bypass Hibernate's event system, so `Interceptor` hooks and JPA lifecycle callbacks such as `@PrePersist` / `@PreUpdate` do not fire. Anything built on that machinery — auditing, generated timestamps implemented as callbacks, event-driven side effects — silently stops working. This is the loss that bites teams hardest in production, because nothing errors; the behaviour just disappears. **Second-level cache interaction.** A stateless session does not read from or write to the second-level cache. Data you modify through it therefore leaves whatever the L2 cache already holds untouched and stale, until it expires or you evict it explicitly. ## When it is the right tool The profile is: high row volume, flat data (no graph to cascade), no domain events needed, and no benefit from an identity map. Concretely — importing a file into a table, migrating or backfilling data, copying between systems, feeding a search index, mass-deleting archived rows. In those jobs the persistence context is pure overhead: memory that grows, snapshots you never diff, a flush that scans entities you already know are dirty. ## When it is the wrong tool Ordinary application logic. If you need cascades, lifecycle callbacks, lazy navigation, the identity map, or the second-level cache — that is to say, most request-scoped domain work — use a regular `Session`. Reaching for a stateless session because it is "faster" and then hand-rolling the machinery you removed is a net loss. ## The honest comparison The realistic alternative to `StatelessSession` for a bulk job is a regular `Session` with JDBC batching enabled and a `flush()` + `clear()` every N rows. That keeps cascades, events and lazy loading while bounding memory. `StatelessSession` is a step further: less machinery, less overhead, fewer surprises about what will be flushed — but you own the correctness of the write sequence. Being able to describe *both* and pick between them is what distinguishes a solid answer.