BPEL processes are mainly two kinds:
transient and durable.
Durable process: BPEL processes of this kind are dehydrated on the fly when a breakpoint or non-idempotent activity is encountered. In the event of a server crash, the BPEL process restarts from the last dehydration point.
A very important detail is that if a BPEL process fails without reaching a dehydration point then the instance will not show up on the BPEL console. This instance never gets stored to the database.
Dehydration can be forced in several ways
· adding check points
· by setting the idempotent property to false
· adding mid receive activity – if the process needs to wait for an event
Transient process: These are the
kind that does not have any break activity or mid receive activity in their
design. Dehydration process occurs at the end of the process. If the BPEL
process crashes before finishing, then the instance is lost. We will not find
the traces of this process in the dehydration store. To java folks, this is
very much similar to a transient variable. When explicitly declared as
transient the variable will not be persisted with the object state and cannot
be serialized.
Durable process: BPEL processes of this kind are dehydrated on the fly when a breakpoint or non-idempotent activity is encountered. In the event of a server crash, the BPEL process restarts from the last dehydration point.
A very important detail is that if a BPEL process fails without reaching a dehydration point then the instance will not show up on the BPEL console. This instance never gets stored to the database.
Dehydration can be forced in several ways
· adding check points
· by setting the idempotent property to false
· adding mid receive activity – if the process needs to wait for an event
No comments:
Post a Comment