#40 - do not flush anymore as that is handled by quartz plugin

[zyro23]

would be great if this gets released as 1.3.1 or 1.4.0. thank you!

i tested locally published to maven local as 1.3.1.BUILD-SNAPSHOT with an app that uses hibernate-5.2 and threw an exception before (on flush by QuartzDisplayJob). no more exception after the change.

[jamescookie]

The reason I flush the session is because the job may fail when session is flushed, but I would have already marked it (incorrectly) as successful. If there is a way to flush the session and avoid the exception being thrown, then by all means submit a PR, but I am going to close this one.

[zyro23]

thank you for the feedback! really glad to see this plugin is still maintained.

sure, i could also send a pr that uses the persistenceInterceptor or checks explicitly if the flush mode is not MANUAL or COMMIT - and only flush then.

but id like to really understand this point. what is flushed here that did not yet get processed by the SessionBinderJobListener?

https://github.com/jamescookie/quartz-monitor/blob/master/src/main/groovy/grails/plugins/quartz/QuartzDisplayJob.groovy#L34 will execute the job and that will call the SessionBinderJobListener during its execution lifecycle which in turn does already flush if it is necessary. if an exception happens there, that will be propagated up to the QuartzDisplayJob (https://github.com/grails-plugins/grails-quartz/blob/v2.0.12/src/main/groovy/grails/plugins/quartz/GrailsJobFactory.java#L99), right? as i understand it, then jobDetails.status = "error" will be set correctly.

if quartz is using a jdbc store, that is unrelated i think because it has nothing to do with hibernate.

[jamescookie]

Certainly the code in SessionBinderJobListener looks like it will do the job. It has changed a lot since I last looked (a few years ago), I will have to test it out to see if it works as I imagine it will. I don't have a lot of time right now, but I will get around to it.