We are using JDeveloper 18.104.22.168 and JHS 22.214.171.124. The Application modules are derived from JhsApplicationModuleImpl. It looks as though the prepare session does getDBTransaction().setClearCacheOnRollback(false);
We have a taskflow for pop-ups that contains a save and cancel button plus the dynamic region content. The idea is that the save will invoke the return activity that performs a commit. This will also close the popup-window. The cancel button is similar to the save button, but the return activity will end the transaction with a rollback. This seems to notify ALL accessed view objects to issue a rollback. This causes each view object to clear their cache and then re-execute the query.However, when the rollback happens it causes all the active views to be cleared and requeried. This is a performance issue as all the JHS user, module, menu and permission data is requeried.
I have also tried using the taskflow savepoints and the same behaviour is observed.
It seems as though the setClearCacheOnRollback may not be adhered to or the assumption has changed.
I can also look at doing something different, but this seems to be a bit of an issue with the JHS extensions and / or ADF. My something different involves a managed bean that can invoke the actual rollback for the view object in question.
Thanks Steven. On testing, this was BLAZING fast. However, it means passing keys between the parent and child taskflows. Fortunately I already pass around the keys and an iterator as it will require finding the information interested in the new data control scope.
Have a great day!