1 2 Previous Next 17 Replies Latest reply on Jan 12, 2009 10:37 AM by tbee

    dual jbpm context

    tbee

      Ok, I've got my JBPM environment up and running now, aside from one thing: I want to be able to have long running process (stored in the database) and short term processes (which are kept in memory) preferably totally without Hibernate.

      1. I assume I need to configure two jbpm.cfg.xml and use JbpmConfiguration.getInstance(String) do denote which one I want. Correct?

      2. Cannot I just leave out the persistence service, and there are not sensible classes in org.jbpm.persistence so how does one disable the persistency?

        • 1. Re: dual jbpm context
          tbee

          2. Or do I have to configure hibernate to use hsqldb in memory mode?

          • 2. Re: dual jbpm context
            tbee

            1. Having two JbpmConfigurations runs into some dead ends.

            When trying to parse a ProcessDefinition from String using the static parseXmlString, underwater JbpmConfiguration.getInstance() is called.

            JbpmConfiguration.getInstance(String) line: 278
            JbpmConfiguration.getInstance() line: 257
            JbpmConfiguration$Configs.getObjectFactory() line: 425
            JbpmConfiguration$Configs.getObject(String) line: 437
            JbpmConfiguration$Configs.getString(String) line: 441
            ProcessDefinition.createNewProcessDefinition() line: 97
            JpdlXmlReader.readProcessDefinition() line: 138
            ProcessDefinition.parseXmlString(String) line: 150

            Since I do not have a jbpm.cfg.xml anymore, it will revert to the embedded one. That is not the idea with having two separate configurations...

            • 3. Re: dual jbpm context
              tbee

               

              "tbeernot" wrote:
              When trying to parse a ProcessDefinition from String using the static parseXmlString, underwater JbpmConfiguration.getInstance() is called.


              The problem basically is with the static ProcessDefinition.createNewProcessDefinition; it accesses a static inner class Configs:

              String resource = JbpmConfiguration.Configs.getString("resource.default.modules");

              That will result in trying to get the factory, which will see if an instance is available via the depricated method:

              JbpmContext jbpmContext = JbpmContext.getCurrentJbpmContext();

              Which ends up in JbpmConfiguration.jbpmConfigurationsStacks (a ThreadLocal variable).

              If no instance is available, it will generate the default one, thus accessing jbpm.cfg.xml.

              The approach would then have to be to push the active configuration on the thread local stack before each call and pop it afterwards.

              This does not feel right.

              • 4. Re: dual jbpm context
                kukeltje

                huh? can't you use to different named context in one config? One pointing to a hibernate config with persistance and one without?

                USe http://docs.jboss.org/jbpm/v3/javadoc/org/jbpm/JbpmConfiguration.html#createJbpmContext(java.lang.String) then

                • 5. Re: dual jbpm context
                  tbee

                   

                  "kukeltje" wrote:
                  huh? can't you use to different named context in one config? One pointing to a hibernate config with persistance and one without?

                  USe http://docs.jboss.org/jbpm/v3/javadoc/org/jbpm/JbpmConfiguration.html#createJbpmContext(java.lang.String) then


                  I'm using two configs files here, haven't tried this. How would that look?

                  • 6. Re: dual jbpm context
                    kukeltje

                    put 2 jbpm-context in one config file and put a name attribute on each them

                    • 7. Re: dual jbpm context
                      tbee

                       

                      "kukeltje" wrote:
                      put 2 jbpm-context in one config file and put a name attribute on each them


                      I dunno; what to do with lines like this:

                      JbpmConfiguration.getInstance().createSchema();


                      It should be done like:

                      JbpmConfiguration.getInstance().createJbpmContext("mem").createSchema();


                      But that is not possible.

                      I have the impression that the whole API is not fully worked out. Maybe I should wait for the 4.0 release...

                      • 8. Re: dual jbpm context
                        tbee

                         

                        "tbeernot" wrote:

                        JbpmConfiguration.getInstance().createSchema();



                        Ah, oeps:

                        JbpmConfiguration.getInstance().createSchema("mem");



                        • 9. Re: dual jbpm context
                          tbee

                          Ah... I finally "get" it.

                          If I want long running workflows, I use the JbpmContext and go off and persist it. Then I need to hold the id in session.

                          If I only want to do stuff in memory, I cannot use the JbmpContext at all, notably not for "findLatestProcessDefinition", since there is no store. I have to recreate a ProcessDefinition from the XML definition each time and store the process definition instace in the session.

                          • 10. Re: dual jbpm context
                            kukeltje

                            That is another option.... I use the 'mem' option with an in-memory database and when starting the app, I deploy the process to there. I also remove process instances from the in-memory database when they end... works great

                            • 11. Re: dual jbpm context
                              tbee

                               

                              "kukeltje" wrote:
                              That is another option.... I use the 'mem' option with an in-memory database and when starting the app, I deploy the process to there. I also remove process instances from the in-memory database when they end... works great


                              Doesn't this cause cleanup issues? When sessions are terminated? Or better; when the user simply cancels thus you never know it is terminated?

                              And technically you do not have an "no-persistence" setup; you have two persisted configurations, but one DB happens to be in-memory. (I tried you setup with hybernate removed from the configuration, but that does not work).

                              I want all in-memory processes to be cleared when the session is destroyed (explicitely or due to time out).


                              • 12. Re: dual jbpm context
                                kukeltje

                                 

                                "tbeernot" wrote:

                                Doesn't this cause cleanup issues? When sessions are terminated? Or better; when the user simply cancels thus you never know it is terminated?


                                No, use an HttpSessionListener, declare it in the web.xml and implement the sessionDestroyed method. In the session you can keep the processInstanceId and use that to cancel/remove the process. When the use clicks cancel it is (to me) obviously easier....

                                "tbeernot" wrote:

                                And technically you do not have an "no-persistence" setup; you have two persisted configurations, but one DB happens to be in-memory. (I tried you setup with hybernate removed from the configuration, but that does not work).

                                Correct... but what I do not get is what you mean by 'with hibernate removed'. I have hibernate in both configs.

                                "tbeernot" wrote:

                                I want all in-memory processes to be cleared when the session is destroyed (explicitely or due to time out).


                                See my first statement. You can also link it e.g. to seam conversation timeouts etc...

                                • 13. Re: dual jbpm context
                                  tbee

                                   

                                  "kukeltje" wrote:
                                  No, use an HttpSessionListener, declare it in the web.xml and implement the sessionDestroyed method. In the session you can keep the processInstanceId and use that to cancel/remove the process. When the use clicks cancel it is (to me) obviously easier....


                                  Ah, yes, the session listener; that was added after I got knee deep in the servlet API and I keep forgetting it exists. Dumm me.

                                  "kukeltje" wrote:
                                  Correct... but what I do not get is what you mean by 'with hibernate removed'. I have hibernate in both configs.


                                  Well, in one of you previous posts you said this:

                                  "kukeltje" wrote:
                                  One pointing to a hibernate config with persistance and one without?


                                  "Without persistence", for me that means "no persistence" and not "in-memory db", so I took hibernate out of the one configurations. As said; that didn't work. ThenI reread that part on the XML vs objects vs DB and finally saw the light; you either have a backing store (and can base on workflows stored in there), or you don't.

                                  So thanks again!

                                  Tom

                                  • 14. Re: dual jbpm context
                                    kukeltje

                                     

                                    Well, in one of you previous posts you said this:


                                    One pointing to a hibernate config with persistance and one without?


                                    "Without persistence", for me that means "no persistence" and not "in-memory db", so I took hibernate out of the one configurations. As said; that didn't work. ThenI reread that part on the XML vs objects vs DB and finally saw the light; you either have a backing store (and can base on workflows stored in there), or you don't.


                                    That is what you get when non native english speakers start writing short statements. Persistence to me is 'surving restarts'



                                    1 2 Previous Next