Currently I have a BPEL set to async.persist, which is not rolling back a transaction as I Catch All a DB fault, store the message, then terminate the process. In one test, I did throw a rollback from the Catch All. This did roll back the transaction but it keeps the Instance state as "Running". Since at that point of manually throwing a rollback I am out of the Catch All, placing a Terminate activity after throwing the rollback doesn't work. I then changed my oneWayDeliverPolicy to sync.cache which did not commit any data to the database if a fault occurred.
What are some of the disadvantages of using sync.cache?
If you don't want save the faulted instances .you can use the persitent properties.
The givenbelow properties will not the save the faulted instances.
< property name="bpel.config.inMemoryOptimization">true</property>
Can you provide more details on the use-case? Is it only one BPEL process or two BPEL processes and calling one from the other? How is the BPEL process initiated (say, as a Web Service or by an adapter). And, I believe you changed oneWayDeliveryPolicy to either "sync" or "async.cache" (there is no value as "sync.cache", only "async.cache")?
It is initiated by an adapter and according to Transaction and Fault Propagation Semantics in BPEL Processes
it is a valid value. Also, I get the desired result using sync.cache and not sync, or async.cache.
Maybe it's a documentation error in 126.96.36.199 (http://docs.oracle.com/cd/E15586_01/integration.1111/e10224/soa_transactions.htm#CHDBIDAA) that a property named "sync.cache" is mentioned. In 188.8.131.52.3 documentation (http://docs.oracle.com/cd/E23943_01/dev.1111/e10224/soa_transactions.htm#CHDBIDAA), it's mentioned only "async.cache" (and can see this property option in JDev, but not "sync.cache"). Anyway, using this property, the invocation/delivery message is stored in memory, hence the disadvantage is that the message is lost when there is a server failure. Using "sync" option will make the transaction execute in the same thread and it will help in transaction rollback.
Hi S.Ananth. I am experiencing inconsistent results with using these properties so I looked into manually throwing a RollBack fault when an error occurs. This does roll back the transaction but it leaves the composite instance in an error state of 'running'. Oracle documentation states that you cannot catch RollBack fault. Since that fault cannot be caught that means we are no longer in the composite therefore cannot "Terminate" the process. It seems to be a bug by Oracle that they do not terminate an instance when a fault is thrown outside of a composite. Does anyone know a way to terminate this instance?