Index Changes
Page Difference

Difference between version and version     

Back to M Eprocessing And Property Propagation, or M Eprocessing And Property Propagation Info


At line 20 added 1 line.
*Correlating Messages (In or InOut), no behavior change.
At line 23 changed 3 lines.
* When business process execution time is predictable and short interval acknowledgment can be delayed for the duration of instance execution. For these scenarios this is preferred option.
* No message loss would be experienced. No need to persist the state of the business process. "Persistence Enabled" attribute has no influence. Potential duplicates are possible in the event of crash or failure in the execution. In the event of crash partner would redeliver the message and all the activities in the business process would be re executed.
* By associating Message with transaction we could achieve "once-only-once" semantics. Partner needs to support XA. Please note that "unique-id" does not help to achieve "once-only-once" as BP state is not persisted.
*When business process execution time is predictable and short interval acknowledgment can be delayed for the duration of instance execution. For these scenarios this is preferred option.
*No message loss would be experienced. No need to persist the state of the business process. "Persistence Enabled" attribute has no influence. Potential duplicates are possible in the event of crash or failure in the execution. In the event of crash partner would redeliver the message and all the activities in the business process would be re executed.
*By associating Message with transaction we could achieve "once-only-once" semantics. Partner needs to support XA. Please note that "unique-id" does not help to achieve "once-only-once" as BP state is not persisted.
*Correlating Messages (In or InOut). There is potential of message loss as well as duplicates based on timing of execution.
At line 49 changed 1 line.
Both InOnly and InOut , "Model - A" execution mode, For correlating messages message loss & duplicate message issue can be addressed by associating transaction or tagging with unique id. It is semantically "once-only-once". For correlating message "Model-B" is not preferred as there is potential of message loss as well as duplicates.
!!Correlating Message Exchange
!atomic=no
Both InOnly and InOut message loss & duplicate message issue can be addressed by associating transaction or tagging with unique id. It is semantically "once-only-once".
!atomic=yes
For correlating message "Model-B" is not preferred as there is potential of message loss as well as duplicates.
G'day, Anonymous Guest

JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This page (revision-29) was last changed on 18-Nov-08 16:16 PM, -0800 by Murali