Did you ever had an idea to implement centralized Commit/Rollback management in ADF application. This would allow to save development time, no need to create Commit/Rollback operation in each page definition file - forget about this. You can manage transaction on ADF Data Control level and I will show you how with this sample application - GlobalTransactionControlApp.zip.
Sample application contains two Application Modules, we need to have two in order to test if both of them will be commited/rollbacked together through our centralized transaction management solution:
There is fragment template implemented to keep our global Save/Cancel button for Commit/Rollback:
Fragment template contains two regular buttons in the toolbar:
Each button is calling Action Listener method from managed bean:
Here is real main point of this post - Java code to execute generic Commit/Rollback action for every active Data Control. This code is iterating over active Data Controls and if transaction is dirty it performs Commit or Rollback:
This allows to skip Commit/Rollback operations definition in every single page definition file and saves development time.
Here how it looks on UI - we display data from different Application Modules but there is only one Save button:
This button is forcing to commit all pending changes from centralized method:
If exception happens, we catch it and display to the user.
Sample application contains two Application Modules, we need to have two in order to test if both of them will be commited/rollbacked together through our centralized transaction management solution:
There is fragment template implemented to keep our global Save/Cancel button for Commit/Rollback:
Fragment template contains two regular buttons in the toolbar:
Each button is calling Action Listener method from managed bean:
Here is real main point of this post - Java code to execute generic Commit/Rollback action for every active Data Control. This code is iterating over active Data Controls and if transaction is dirty it performs Commit or Rollback:
This allows to skip Commit/Rollback operations definition in every single page definition file and saves development time.
Here how it looks on UI - we display data from different Application Modules but there is only one Save button:
This button is forcing to commit all pending changes from centralized method:
If exception happens, we catch it and display to the user.
8 comments:
Hi! Thank you for this post.
But how to handle distributed transaction in case if we cannot allow first commit if the second commit fails?
Hi,
This is not related to this post, here I'm showing regular commit operation. You will face same problem even with default Commit operation in Page Definition.
For your use case, you would need to use Save Points functionality. Or you can try to post data to DB and commit all AM's at the end if transaction posts are successful.
Andrejus
I know, and I have faced them already. I didn't solve them correctly.
I think there's a way to do handle it using Weblogic's distributed transaction capabilities: when you create brand new datasource in WLS there are some options according to distibuted transactions handling.
Maybe somehow we should use them.
When developing plain Java app on top of JDBC - probably yes. But with ADF - remember that transaction is managed on AM level, not on WLS Data Source level.
Andrejus
Hi! Nice post and idea! But don't think that rollback function will be ok because we need to handle currentRowIndex of current view object after executing rollback (rollback will reset to first row).Maybe it's better to put methods in some utility class and call on every page.
This is not related. Keep in mind, this post about centralizing rollback invocation - it just you dont need to create Rollback and Commit bindings in every Page Def.
You need to override VO Row Implementation class anyway in both cases (Rollback operation and Page Def and this approach) - if you want to keep current row.
I hope it makes sense now.
Andrejus
Thanks a lot for the explanation! Now found example how to override VO Row Implementation class - https://blogs.oracle.com/smuenchadf/resource/examples#68. I have not tried this way before, always using backing bean. Yes, now it make sense. Everything is cool now :)
Hi Andrejus,
Nice post,How can we achieve a central record navigation from multiple application modules & different viewobject?
Thanks.
Post a Comment