The GitHub Actions job "Code Style" on 
grails-core.git/fix/readonly-no-flush-8.0.x has failed.
Run started by GitHub user codeconsole (triggered by codeconsole).

Head commit for run:
fd1f4f3e34e4fb72fef394969394653ea22a5b54 / Scott Murphy Heiberg 
<[email protected]>
Honour read-only transactions on the DatastoreTransactionManager path

@ReadOnly means different things depending on the datastore. On Hibernate it
genuinely suppresses the flush:

    // GrailsHibernateTransactionManager:55
    if (definition.isReadOnly()) {
        holder.session.setHibernateFlushMode(FlushMode.MANUAL)
    }

On the DatastoreTransactionManager path there was no equivalent. doBegin set
FlushModeType.COMMIT, which is already the Session default and is as strict as
the JPA enum gets, and doCommit's `if (!status.isReadOnly())` guard was then
defeated by transaction.commit() — both MongoTransaction and
SessionOnlyTransaction flush unconditionally. A read-only transaction therefore
wrote whatever the surrounding session had queued.

Session.beginTransaction(TransactionDefinition) already existed for this;
AbstractSession discarded the argument. It now passes the definition to an
overridable beginTransactionInternal(TransactionDefinition) whose default
delegates to the no-arg version, so datastores that do not override it — Neo4j
and the simple map datastore — keep exactly the path they had. Mongo overrides
it, and both transaction types decline to flush when the definition is
read-only.

A read-only transaction has no pending operations of its own, so the only
writes this suppresses are ones a read had no business flushing. Read-write
commits are unchanged, which the added tests assert alongside the read-only
case on both the server-transaction and session-only paths.

Report URL: https://github.com/apache/grails-core/actions/runs/32788788689

With regards,
GitHub Actions via GitBox

Reply via email to