The GitHub Actions job "CI - Groovy Joint Validation Build" on grails-core.git/fix/readonly-no-flush-8.0.x has succeeded. Run started by GitHub user codeconsole (triggered by codeconsole).
Head commit for run: 05fb17e72271e28b116a6cf91a8918b9465bb8c2 / Scott Murphy Heiberg <[email protected]> Give read-only transactions the same meaning on Mongo as on Hibernate @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/32791117146 With regards, GitHub Actions via GitBox
