Incorrect OSB JCA transaction spanning

Question

Hi!
I have set up a service in OSB which polls database using a dbAdapter, does some processing of the data read and then inserts data in database using a different dbAdapter.
The service is composed as follows. First I built a proxy service from JCA adapter which polls an XML registry from database. This proxy makes a service callout to another proxy which performs some transformations and finally routes to a JCA dbAdapter business service which writes to database.
I need full process to be transactional, so If any error occurs at any step, register should not be marked as read in polled database and no data should be written to database. I have configured polling proxy as transactional and invoked proxy which performs writting to database as transactional too. I've tested that when a writting error occurs, polled data is not marked as read, which is expected behaviour. But if I rise an error in polling proxy after service callout is effectuated, then register is not marked as read but data is written to database in called proxy.
Could anyone tell me how to configure transaction behaviour in proposed scenary?
Thank you in advance.

Answer 1

After some research I saw following section in http://download.oracle.com/docs/html/E15867_01/proxy_services.htm#i1316487
"If the message flow run time starts a transaction, quality of service is exactly-once. However, if Service Callouts or Publish actions have the outbound quality of service parameter set to best-effort (the default), Oracle Service Bus executes those actions outside of the transaction context. To have Oracle Service Bus execute those actions in the same request transaction context, set quality of service on those actions to exactly-once."
It seems default qualify of service for Service Callouts is best effort so services called are executed in a different transaction than the caller. That's pretty clear then.
But after replacing the qualify of service the process stopped working when activating the polling.
When I started testing the process I noticed that after polling I got more registers in target table than the total number of polled registers in source table, indicating that some of the source registers where been processed multiple times. As polled registers count must be equal to written registers count, I assumed the difference could be caused because an error occurred after commiting transaction in proxy 2 which performs the write operation. That's why I need full process to be executed in same transaction context.
Thanks.