MyDomain.withNewTransaction {
new MyDomain(name:'Jeopardy').save() // << Event is thrown here
sleep(20000) // << I added this just so that I could assert through the front-end that the business logic has indeed been invoked before the transaction ended
throw new Exception("but it fails!") // << this causes rollback, so the MyDomain instance is not saved
}
--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-disc...@googlegroups.com.
To post to this group, send email to grails-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grails-dev-discuss/ca5b8426-faca-4bf4-a821-3759fe6eebee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
If your business logic involves updating Database, then it should be fine. But if it involves archiving files, sending mails or raising audit events etc then either you need to have an explicit rollback(for example files can be un-archived in case of rollback, and a followup audit event can be raised) for the business logic, or you need to queue the tasks in afterUpdate (and related functions) and invoke them at commit. For example mails should be sent only after all DB operations has been committed.
It depends on what is the business logic that gets executed at each db commit. If anybody can suggest a better approach please do because AFAIK business logic executed prior to commit needs to be manually handled in case of rollback.
Regards
Arvind Sachdeva.
--
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-discuss+unsub...@googlegroups.com.
To post to this group, send email to grails-d...@googlegroups.com.
> To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-discuss+unsub...@googlegroups.com.