2 Replies Latest reply on Sep 1, 2006 3:11 PM by Tom Baeyens

    tx configs and command interface for web app

    Tom Baeyens Master

      i'm starting to see a problem here. please think along and give your opinion:

      currently the webapp just uses creates jbpmContexts and performs operations on the jbpmContext in the backing beans. there can only be 1 hibernate configuration that is used in the webapp. so you need to do a non-CMT based configuration. in case users want to use the enterprise beans, this would imply that we have to create 2 jbpm configurations on jboss: one for the webapp (without CMT configurations) and one for the CMT enterprise beans. hmmm let me know if you don't follow this then i'll try to explain in different words.

      could it be that we need to solve this by implementing the command based interface between the web app and the jbpm command service ? that way, the command service implementation can be the enterprise command service SLSB or in a plain web application packaging, the command service bean could be a simple POJO based command service.

      makes sense ?

      i'll sleep on it. maybe that helps

        • 1. Re: tx configs and command interface for web app
          Koen Aers Master

          Is this already solved? Can the two configurations (one for the webapp and one for the EE service) not live together? Relying on the command interface will result in problems trying to port the webapp on containers like Tomcat, no?


          • 2. Re: tx configs and command interface for web app
            Tom Baeyens Master

            the problem is that with a command interface, i don't see a way to prevent many small transactions during the rendering phase.

            doing it with commands, each backing bean that is accessed during rendering of a page would result in a separate transaction.

            i don't see a way around that with jsf and ejb cmt.

            unless we use JTA directly (through the UserTransaction) we can't make sure that the rendering is done in one transaction. but then all the commands are executed in the same transaction. which conflicts with the idea of the each command being executed in one transaction...

            using the UserTransaction, we can get the exact same behaviour in enterprise as in standard edition. namely one transaction for the user command (if there is one) and one transactino for the rendering phase.