2 Replies Latest reply: Apr 25, 2013 1:59 AM by Wooi Joe Chuah RSS

When to call kSession.dispose()?

Ryan Peterson Newbie

I was wondering:  How often should kSession.dispose() be called for any given session?

 

For instance, suppose you have the following:

 

// create kSession

JPAKnowledgeService.newStatefulKnowledgeSession()

 

// do some operations with kSession:

ksession.getWorkItemManager().registerWorkItemHandler(x, y);

...

// start the process instance

kSession.startProcess(processId, params)

 

// Should kSession.dispose() be called here, since we're done doing work on the ksession for now?

 

Suppose we re-load the session later:

JPAKnowledgeService.loadStatefulKnowledgeSession()

 

// Should kSession.dispose() only be called here?

 

I'm mostly unsure if .dispose() needs to be called after each transaction with a kSession, or if it should only be called once the kSession is complete/aborted?

  • 1. Re: When to call kSession.dispose()?
    Sukumaran Raghavan Newbie

    +1 ....

    I use multiple sessions in my application and i dispose these as soon as i create a new process instance (basically each process instance has its own session). Once i register the work item, i dispose the ksession. I have also passed the ksession as a parameter to my work item handlers and they in turn save the ksession. Basically i want to call ksession.getWorkItemManager().completeWorkItem(workItemId).

     

    Now i am not sure if that call will work or not. It seems to work which is surprising. especially since i disposed my ksession ?

    How does this all work ? A lil clarity would help me make more apt design decisions.

     

    Thanks in advance.! !

  • 2. Re: When to call kSession.dispose()?
    Wooi Joe Chuah Newbie

    If I'm not mistaken.

     

    Your process can either work in 2 ways.

     

    First if the process completes without persistence (startProcess completes the entire processInstance). Hence, the ksession within the workItems are still there before dispose is called.

     

    Second scenario is with persistence. When your process stops somewhere the current processInstanceInfo is saved. When you want to resume the process a new ksession is created and

    the workItemHandlers are registered again. The processInstance can still proceed smoothly using the new ksession.