-
1. Re: how crucial are exception handlers ?
heiko.braun Feb 26, 2008 11:06 AM (in response to tom.baeyens)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 Feb 26, 2008 11:07 AM (in response to tom.baeyens)BTW, could you point to some examples of 'delegation classes'?
-
3. Re: how crucial are exception handlers ?
kukeltje Feb 26, 2008 7:35 PM (in response to tom.baeyens)'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 Feb 27, 2008 2:52 AM (in response to 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 Feb 27, 2008 4:43 AM (in response to tom.baeyens)Thanks to both of you. Now I get an idea.
-
6. Re: how crucial are exception handlers ?
camunda Feb 28, 2008 5:11 AM (in response to tom.baeyens)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 Feb 28, 2008 6:21 AM (in response to 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 Feb 28, 2008 6:21 AM (in response to tom.baeyens)on balance, i think i want them in there.
-
9. Re: how crucial are exception handlers ?
camunda Feb 28, 2008 6:33 AM (in response to tom.baeyens)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 ?
estaub Mar 6, 2008 9:42 AM (in response to tom.baeyens)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 Mar 7, 2008 3:23 AM (in response to 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 ?
estaub Mar 10, 2008 2:54 PM (in response to tom.baeyens)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 Mar 11, 2008 11:51 AM (in response to 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.