views:

1127

answers:

1

I've upgraded a Grails 1.0.4 application to 1.1.1. After upgrading, I'm repeatedly getting Exceptions when executing my Quartz jobs (using Quartz plugin 0.4.1). The plugin is used to manually schedule jobs using Simple and Cron Triggers via a service (paraphrased code below):

class SchedulerService implements InitializingBean
{
    static scope = 'singleton'
    ...
    def schedule(def batch) {
        JobDetail job = new JobDetail(uniqueId, groupName, BatchJob.class, false, false, true)
        job.jobDataMap.put("batchId", batch.id)

        SimpleTrigger trigger = new SimpleTrigger(triggerId, triggerGroup, 0)

        SchedulerFactory factory = new SchedulerFactory()
        factory.initialize(properties)
        Scheduler scheduler = factory.getScheduler()

        scheduler.scheduleJob(job, trigger)
    }
    ...
}

My BatchJob job is set up as follows:

class BatchJob implements Job, InterruptableJob
{
    static triggers = {}
    void execute(JobExecutionContext context) {
        def batch = Batch.get(context.jobDetail.jobDataMap.getLongValue("batchId"))
        // the next line is "line 49" from the stack trace below
        def foo = batch.batchStatus.description
    }
}

Here's an abbreviated definition of Batch.groovy (domain):

class Batch
{
    BatchStatus batchStatus // relationship
}

However, when schedulerService.schedule() is invoked with an existing, saved Batch, I receive the following Exception:

org.hibernate.LazyInitializationException: could not initialize proxy - no Session
        at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:86)
        at org.codehaus.groovy.grails.orm.hibernate.cfg.GrailsHibernateUtil.unwrapProxy(GrailsHibernateUtil.java:311)
        at org.codehaus.groovy.grails.orm.hibernate.cfg.GrailsHibernateUtil$unwrapProxy.call(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
        ...
        <b>at BatchJob.execute(BatchJob.groovy:49)</b>
        ...

I've tried the following actions to fix this, but none have worked:

  • I've specified static fetchMode = [batchStatus: 'eager'] on my Batch domain class
  • I've used static mapping = { columns { batchStatus lazy:false }} on my Batch domain class
  • I've tried using batch.attach() after calling Batch.get() in the Job

I can't use BatchJob.triggerNow() in this instance, because this is only one of a couple examples - the others are still scheduled by the service, but might be scheduled as a cron job or otherwise. I should mention that I did upgrade the Quartz plugin as well when upgrading Grails; the previous Quartz version was 0.4.1-SNAPSHOT (as opposed to the upgraded version, just 0.4.1).

How do I get Hibernate sessions to work correctly in these manually-triggered Quartz Jobs?

I've also sent this question to the grails-user mailing list, as for a more niche issue like this, the list seems to elicit a bit more response. I'll update this question with an answer if one comes out of there. Here's a link.

A: 

Check out jira issue 165 (http://jira.codehaus.org/browse/GRAILSPLUGINS-165) There are also clues in the Quartz Plugin (which you may like to check out) This code was used with the JMS plugin which seems to work well.

try

    import org.hibernate.FlushMode
    import org.hibernate.Session
    import org.springframework.orm.hibernate3.SessionFactoryUtils
    import org.springframework.orm.hibernate3.SessionHolder

    class BatchJob implements Job, InterruptableJob
    {
        static triggers = {}
        void execute(JobExecutionContext context) {
           Session session = null;   
           try { 
              session = SessionFactoryUtils.getSession(sessionFactory, false); 
           }
           // If not already bound the Create and Bind it! 
           catch (java.lang.IllegalStateException ex) { 
              session = SessionFactoryUtils.getSession(sessionFactory, true);  
              TransactionSynchronizationManager.bindResource(sessionFactory, new SessionHolder(session)); 
           }
          session.setFlushMode(FlushMode.AUTO);
          if( log.isDebugEnabled()) log.debug("Hibernate Session is bounded to Job thread");

        // Your Code!
        def batch = Batch.get(context.jobDetail.jobDataMap.getLongValue("batchId"))
        // the next line is "line 49" from the stack trace below
        def foo = batch.batchStatus.description



        try {
         SessionHolder sessionHolder = (SessionHolder) 
         TransactionSynchronizationManager.unbindResource(sessionFactory);
         if(!FlushMode.MANUAL.equals(sessionHolder.getSession().getFlushMode())) {
           sessionHolder.getSession().flush(); 
         }
         SessionFactoryUtils.closeSession(sessionHolder.getSession());
         if( log.isDebugEnabled()) log.debug("Hibernate Session is unbounded from Job thread and closed");
       }
       catch (Exception ex) { 
         ex.printStackTrace(); 
       }
   }
}

Hope this helps. It worked for me.

Scott Warren
Scott, thanks for the answer. A couple questions: 1) is the `sessionFactory` instance injected (i.e. `def sessionFactory`), or is it configured via XML bean configuration - `sessionFactory` is null when I pass it to `getSession()`; 2) I've made some assumptions about which imports to use for the code you've specified and added them to the code snippet in your answer - can you verify them? Thanks again.
Rob Hruska
To add to my comment above, I took a look at the code for SessionBinderJobListener (on which this sample code is based) http://svn.codehaus.org/grails-plugins/grails-quartz/tags/RELEASE_0_4_1/src/java/org/codehaus/groovy/grails/plugins/quartz/listeners/SessionBinderJobListener.java , and it looks like it's got accessor methods for its `sessionFactory`.
Rob Hruska
I looks like you are on the right track. Sorry for the delay getting back.
Scott Warren
I haven't had time to revisit this issue, but the last time I worked with it I was still having some troubles with this. However, I believe those troubles are due to the way we're using Quartz, and I believe that I can rearchitect what we're doing to make it work correctly. I'll accept this answer since I believe it'll solve most other peoples' problems if they encounter something similar.
Rob Hruska