13 Replies Latest reply on Mar 11, 2008 11:51 AM by tom.baeyens

    how crucial are exception handlers ?

    tom.baeyens

      i'm in doubt about the importance of exception handlers in the PVM. i want your opinion on whether they should go in the PVM.

      exception handlers are only to catch java exceptions that occur in user code (delegation classes). The purpose of exception handlers is to create global catch clauses that handle certain exceptions for multiple invocations of user code. This way, the try-catch doesn't have to be programmed into each user-code-class individually.

      users could create abstract base classes to include the handling of exceptions and handle it that way. but that would not give the flexibility of the parent lookup of exception handlers. (i'm in doubt if that is needed)

      also, if we do it on the level of the pvm, exception handlers don't make a distinction between process language code and real user code in case of jPDL. the node behaviour implementation is considered a delegation class and hence guarded with the exception handler. but for the exceptions that are thrown, the pvm doesn't know if it comes from the process language implementation or from real user code.

      an alternative could be interceptors. i have in jPDL a mechanism for installing an interceptor for user code. i could do something like that in the PVM as well. that could be an alternative way to enable exception handling functionality to clients of the pvm. the question there would be: what levels would we support interceptors: in jpdl now, it is a static member field, so it's only on the level of the complete engine. But we could also support it on process definition, delegation or even on execution instance level.

      those are my thought pieces that don't come to conclusion. your thoughts are appreciated.

        • 1. Re: how crucial are exception handlers ?
          heiko.braun

          I don't know much about the extension point you are describing,
          but does it help to distinguish user code from PVM by using checked vs. unchecked exceptions?

          That basically means no exception handlers required if the extension point doesn't allow checked exceptions. So the PVM would just guard runtime exceptions.

          • 2. Re: how crucial are exception handlers ?
            heiko.braun

            BTW, could you point to some examples of 'delegation classes'?

            • 3. Re: how crucial are exception handlers ?
              kukeltje

              'Examples' of delegation classes are the implementations of the different node types (e.g. fork etc). A custom one is the costom fork example in the wiki. Actions are also delegation classes but those are not node implementations. A fairly complete one is the esb action.

              Sorry, but I do not have access to the sourcecode now, so cannot give explicit classnames here.

              • 4. Re: how crucial are exception handlers ?
                tom.baeyens

                Delegation classes are all the classes not part of the PVM that are included into the process execution.

                jbpm.3 has interfaces Action, AssignmentHandler, EmailAddressresolver and maybe a couple of others

                pvm has Activity, ExternalActivity and Condition. The PVM delegates the runtime behaviour of the node implementations to Activity implementations.

                Let me know if that is not a complete answer

                • 5. Re: how crucial are exception handlers ?
                  heiko.braun

                  Thanks to both of you. Now I get an idea.

                  • 6. Re: how crucial are exception handlers ?
                    camunda

                    In reality I don't like the use of exception handlers in the process too much.

                    On the other hand is fault handling quite important in BPEL, so I think something comparable should be go into jPDL 4 too. So I think exception handlers are important for the language, because they are expected by the users...

                    Even if I agree with you that it could be solved better by abstract base classes or the like.

                    Cheers
                    BErnd

                    • 7. Re: how crucial are exception handlers ?
                      tom.baeyens

                       

                      "camunda" wrote:
                      In reality I don't like the use of exception handlers in the process too much.

                      On the other hand is fault handling quite important in BPEL, so I think something comparable should be go into jPDL 4 too. So I think exception handlers are important for the language, because they are expected by the users...

                      Even if I agree with you that it could be solved better by abstract base classes or the like.

                      Cheers
                      BErnd


                      i didn't really express the value that i see in exception handlers yet. there are now 2 reasons why i think they can be valuable:

                      1) configurability. if you do it in a base class, there is only one, hard-coded way of handling the exception. While if you use exception handlers, you can in the process decide whether you want to send an email to an admin or start another process in case of failure.

                      2) transactions. we can offer the infrastructure to execute the exception handler inside the failing transaction or as a synchronization creating a separate transaction right after the failing transaction rolled back.

                      though both these arguments are maybe not enough to add them...

                      • 8. Re: how crucial are exception handlers ?
                        tom.baeyens

                        on balance, i think i want them in there.

                        • 9. Re: how crucial are exception handlers ?
                          camunda

                          I agree...

                          For the transactions: You can realize that with a base class also... But maybe it is more easy to use for the people if included in the jbpm infrastructure, agreed!

                          • 10. Re: how crucial are exception handlers ?

                            I think it's really important to get rigorous about defining transaction behavior. The default transaction scope across nodes needs to be obvious to the process author. Currently, if I'm not mistaken, the transaction scope is controlled mostly by whether activities are synchronous or not, i.e., by whether a transition is taken within the execute() method of an activity, or a transition is taken because of some external event (e.g., a simple timer node). This is a detail of the implementation of the activity that may not be obvious to the process author.

                            Similarly, the interaction between rollbacks in delegation classes and PVM's process-state persistence needs to be clear.

                            Since Bonita doesn't even allow transactions to span activities, this probably isn't a concern there - it's mostly an issue for JPDL or anything else that tries to address "microflow" requirements.

                            -Ed Staub

                            • 11. Re: how crucial are exception handlers ?
                              tom.baeyens

                              @estaub: point taken.

                              i definitely see that the docs need to be more rigorous in that respect.

                              i don't yet see how we could define more rigorous behaviour in the engine itself. because i don't want to be limited to the bonita behaviour that you describe.

                              this is also a performance issue. for simple processes that don't do heavy operations, spanning the transaction over multiple activities reduces the number of transactions. the transaction has an overhead and also, for each transaction, the runtime data has to be read again from the db.

                              by default, i would like to keep the same behaviour in the process execution itself. but we can definitely provide better choice to the client. my current idea is that we enhance the command based session facade that sits in front of the jbpm-context-blocks. in such a session facade, you could choose to have it operate synchronously or asynchronously.

                              this gives already the easy flexibility for a user to choose whether he wants the process operation to be in the same thread versus a separate thread. but in the process execution, i think we should keep the strategy as it is now, but only document it better.

                              let me know if this doesn't matches your expectations

                              • 12. Re: how crucial are exception handlers ?

                                Tom,

                                Sorry, "rigorous" could be taken in so many ways... I should have been more ... um... rigorous ;-).

                                I meant that it should be easy for someone to understand where the transaction edges are, without digging into the implementation of each delegation class. So part of this is a designer UI issue, but the engine has to behave in a way that the designer UI can predict. Someone modifying the process shouldn't need to exhaustively study the behavior of every component already in the process in order to understand where it will rollback to if an error occurs. [On the other hand, it's very reasonable to expect someone adding a node to understand its transaction semantics.]

                                The engine can help with this by providing a means by which nodes (and transitions) can express their transaction behavior. Clearly there's lots of progress in PVM versus JPDL3. I'm not sure how much more is needed. I don't understand PVM very well... is it valid to have an Activity that is not an ExternalActivity, yet waits for an external event? I hope not - this would mean that the automatic transaction edges caused by wait states are denoted by the class inheritance. This is the kind of "rigor" I'm hoping for in the engine. If the designer UI has access to the activity class, it can introspect and provide visual cues.

                                i don't want to be limited to the bonita behaviour that you describe

                                I couldn't agree more. IMHO, this is a key differentiator for JPDL - the ability to efficiently do "microflows".

                                we enhance the command based session facade that sits in front of the jbpm-context-blocks. in such a session facade, you could choose to have it operate synchronously or asynchronously.

                                Sorry, I don't follow - I don't know enough about where things have gotten beyond JBPM3. By "synchronously", do you mean "in the same transaction"?

                                Thanks,
                                -Ed Staub

                                • 13. Re: how crucial are exception handlers ?
                                  tom.baeyens

                                   

                                  "estaub" wrote:
                                  I meant that it should be easy for someone to understand where the transaction edges are, without digging into the implementation of each delegation class. So part of this is a designer UI issue, but the engine has to behave in a way that the designer UI can predict. Someone modifying the process shouldn't need to exhaustively study the behavior of every component already in the process in order to understand where it will rollback to if an error occurs. [On the other hand, it's very reasonable to expect someone adding a node to understand its transaction semantics.]


                                  I don't see a good way on how transactions could be visualized in the graphical process designer.

                                  The default behaviour of jBPM is simple. As long as the process itself is executing, this is done synchrnously (in the same thread) and hence in the same transaction. This is good in case the processing inbetween the wait states is minimal. For most workflows that include human tasks and other wait states, it usually is a perfect default.

                                  For some kind of batch processes, people will probably want the opposite default. Namely that the transaction is committed after each activity and automatically the next activity should start in a new transaction. I'm thinking of supporting this in jPDL 4 by allowing the user to specify/overwrite the default async continuation behaviour on the process level.

                                  "estaub" wrote:
                                  is it valid to have an Activity that is not an ExternalActivity, yet waits for an external event? I hope not


                                  You are correct. It is not. Wait states *have* to implement external activity.

                                  If an activity can ever get into a wait state, then an external activity has to be implemented.

                                  the naming comes from the fact that the driver for propagating the execution is external to the process during a wait state.

                                  Let me know if you think there is something left which is not rigorous.