API / Apache Grails Interview questions
Explain the execution flow of a GORM save() call under the hood?
Calling save() on a domain instance triggers a defined sequence of validation, event, and persistence steps before anything actually reaches the database, all coordinated by GORM's underlying datastore implementation (Hibernate, by default).
Validation runs first, entirely in memory, against the domain class's declared constraints; only if it passes does GORM proceed to fire any relevant lifecycle events (like beforeInsert) and hand the entity to the underlying Hibernate session. Importantly, the actual SQL INSERT or UPDATE is often not executed immediately — Hibernate frequently batches and defers writes until a flush point (end of the transaction, or an explicit flush call), which is why a save can appear to "succeed" in application code before the corresponding row actually exists in the database yet.
This deferred-flush behavior is a common source of confusion for developers new to Grails: code that calls save() and then immediately runs a raw SQL query against the same table might not see the just-saved row unless a flush has actually happened, since from the database's point of view the write genuinely hasn't occurred yet.
More Related questions...