Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 21 additions & 0 deletions documentation/src/main/asciidoc/introduction/Interacting.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -233,6 +233,27 @@ entityManager.getTransaction().setRollbackOnly();

A transaction in rollback-only mode will be rolled back when it completes.

[[outside-transaction]]
.💀 Using the session with no transaction 💀
****
Comment on lines +236 to +238
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might as well use admonitions instead of emojis?

Suggested change
[[outside-transaction]]
.💀 Using the session with no transaction 💀
****
[[outside-transaction]]
[CAUTION]
.Using the session with no transaction
====

Over the years, we've run into a surprisingly large number of people who insist that they need to access the database with "no transaction" -- which we understand to mean running queries with https://docs.oracle.com/javase/8/docs/api/java/sql/Connection.html#setAutoCommit--[JDBC autocommit mode] enabled.
We're _pretty sure_ that this is almost always a terrible idea, and that most of the people doing this are simply mistaken about some aspect of transaction isolation or of what the use of autocommit implies for the management of pooled JDBC connections.
Comment on lines +239 to +240
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Over the years, we've run into a surprisingly large number of people who insist that they need to access the database with "no transaction" -- which we understand to mean running queries with https://docs.oracle.com/javase/8/docs/api/java/sql/Connection.html#setAutoCommit--[JDBC autocommit mode] enabled.
We're _pretty sure_ that this is almost always a terrible idea, and that most of the people doing this are simply mistaken about some aspect of transaction isolation or of what the use of autocommit implies for the management of pooled JDBC connections.
People frequently express the need to access the database with "no transaction" -- which we understand to mean running queries with https://docs.oracle.com/javase/8/docs/api/java/sql/Connection.html#setAutoCommit--[JDBC autocommit mode] enabled.
We're _pretty sure_ that this is almost always a terrible idea, and that most of the people doing this are simply mistaken about some aspect of transaction isolation or of what the use of autocommit implies for the management of pooled JDBC connections.


With that said, Hibernate grudgingly allows it.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
With that said, Hibernate grudgingly allows it.
With that said, this is technically possible.


If you decide to do this weird thing:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
If you decide to do this weird thing:
If you decide to do this despite our warnings:


- first, satisfy yourself that you're completely comfortable with the fact that _the database will not help you enforce transaction isolation_,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- first, satisfy yourself that you're completely comfortable with the fact that _the database will not help you enforce transaction isolation_,
- first, be aware _the database will not help you enforce transaction isolation_,

- then set link:{doc-javadoc-url}org/hibernate/cfg/JdbcSettings.html#AUTOCOMMIT[`hibernate.connection.autocommit=true`], and
- make damn sure that your connection pool is returning connections with autocommit enabled by default.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- make damn sure that your connection pool is returning connections with autocommit enabled by default.
- be extra careful to set up your connection pool so that it is returning connections with autocommit enabled by default.


In fact, simply don't do this unless you have set up tools to snoop the protocol-level interaction between the JDBC driver and the database server, so that you can verify your understanding of what "no transaction" actually implies.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm really not sure what kind of verifications you're asking for here.


If you think you want to actually _write_ to the database️ with autocommit enabled 🏴‍☠️🏴‍☠️🏴‍☠️,️ that's possible too, but you'll need to either <<flush,`flush()`>> the session explicitly or, even better, use a <<stateless-sessions,stateless session>>.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty sure people know what they want better than us. They might not know what they need, though.

Suggested change
If you think you want to actually _write_ to the database️ with autocommit enabled 🏴‍☠️🏴‍☠️🏴‍☠️,️ that's possible too, but you'll need to either <<flush,`flush()`>> the session explicitly or, even better, use a <<stateless-sessions,stateless session>>.
If you think you need to actually _write_ to the database️ with autocommit enabled,️ that's possible too, but you'll need to either <<flush,`flush()`>> the session explicitly or, even better, use a <<stateless-sessions,stateless session>>.

And don't come complaining to us when your database starts filling up with inconsistent garbage.
// Because you've now been thoroughly warned, and we're going to enjoy laughing at you.
Comment on lines +253 to +254
Copy link
Member

@yrodiere yrodiere Oct 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
And don't come complaining to us when your database starts filling up with inconsistent garbage.
// Because you've now been thoroughly warned, and we're going to enjoy laughing at you.
And keep in mind we will not address any problem resulting from this usage, such as the database filling up with inconsistent data.

****
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If replacing with an admonition:

Suggested change
****
====


[[persistence-operations]]
=== Operations on the persistence context

Expand Down
2 changes: 1 addition & 1 deletion migration-guide.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -181,7 +181,7 @@ Also, a key subgraph now always refers to a `Map` key, and never to an entity id
We encourage migration to the use of the new JPA-standard operations.

Or, alternatively, when building graphs, consider Hibernate's support for
textual link:{user-guide-url}#fetching-strategies-dynamic-fetching-entity-graph-parsing[graph parsing]. See also <<NamedEntityGraph>>.
textual link:{user-guide-url}#fetching-strategies-dynamic-fetching-entity-graph-parsing[graph parsing].


[[removal-annotations]]
Expand Down