Hibernate locking rows when using entityManager.flush()

I have a standard stack Spring / JPA / Hibernate / Oracle, and found out that when I manually control the flush during a transaction, all entities subject to this flush (because of dirty check mainly) are locked in database with a READ lock until the end of the transaction.

We are not using any read lock, we have some write locks but not for the transaction I am testing, and this transaction is not read-only.

Is this standard behavior? Can it be avoided?
On my application, I have a set of queries that are run in a single transaction, they are of any kind, deletion, insertion, and updates. I want to be sure my delete queries are run first, thus the manual flush I need after the delete queries, but I don't want them to be locked in database.

No, it is not on Hibernate, it is done by Oracle.

>The purpose of a DML lock, also called a data lock, is to guarantee the integrity of data being accessed concurrently by multiple users.
...
DML statements automatically acquire locks at both the table level and the row level.

Chunked summary of Locks Obtained by DML Statements

• RS - row share lock
• RX - row exclusive lock
• S - share table lock
• SRX - share row exclusive table lock
• X - exclusive table lock
• SX - subexclusive table lock (synonym for row exclusive lock)

Full documentation about Automatic Locks are available at:

• Release 21c
• Release 12c