# Flushing a StatelessSession

**URL:** <https://discourse.hibernate.org/t/flushing-a-statelesssession/12425>\
**Category:** Hibernate ORM\
**Created:** [September 10, 2026, 5:04am UTC](https://discourse.hibernate.org/t/flushing-a-statelesssession/12425 "2026-09-10T05:04:28Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![zpneun](https://avatars.discourse-cdn.com/v4/letter/z/b2d939/32.png) [@zpneun](https://discourse.hibernate.org/u/zpneun)\
**Post date:** [September 10, 2026, 5:04am UTC](https://discourse.hibernate.org/t/flushing-a-statelesssession/12425/1 "2026-09-10T05:04:28Z")

</div>

In `StatelessSessionImpl`, the `flush()` method is empty. This seems logical given the contract that every method call is sent to the database immediately — in this case, a flush would be unnecessary.

However, a stateless session still does support JDBC batching, which means that the above contract isn’t really true. In fact, each method call immediately results in a SQL statement being generated (and logged!), but it is by no means guaranteed that the statement is sent to the database immediately.

In my opinion, a `flush()` method would make perfect sense in such cases. For example, I would like to be able to programmatically trigger the execution of pending statements — and thus any checks associated with them, such as constraint or `@Version` checks — before the transaction is committed.  
What do you think?

---

<div class="post-metadata">

**Author:** ![beikov](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/beikov/32/258_2.png) [@beikov](https://discourse.hibernate.org/u/beikov)\
**Post date:** [September 10, 2026, 8:30am UTC](https://discourse.hibernate.org/t/flushing-a-statelesssession/12425/2 "2026-09-10T08:30:34Z")

</div>

Hey, I think you should join our [chat platform](https://hibernate.zulipchat.com/#narrow/stream/132096-hibernate-user) and start a discussion there. I would have to dig a bit into the matter, but I think I saw someone suggesting a different API for handling batching on stateless session in the future instead.