You can configure auto refresh for ADF BC cached LOV and this works out of the box, no special coding is needed. My previous post describes how ADF BC session cached LOV behaves - ADF BC Session Cached LOV - Understanding Expire Time. Auto refresh can be configured for both application and session caching. One important thing - auto refresh doesn't work when ADF BC is configured with disconnected mode (ADF BC Tuning with Do Connection Pooling and TXN Disconnect Level). I would guess this is related to DB notification listener, it can't notify about DB changes, when DB connection is being taken from AM.
Make sure to remember to configure AM without disconnected mode. Auto refresh works for both application and session caching levels:
As a reminder - in order to use shared LOV functionality, you must select VO instance for LOV from shared AM configuration. See how it looks in the LOV definition wizard:
Auto refresh functionality is enabled with a single property - AutoRefresh = true. This can be set through VO general properties or directly in the VO source code:
Make sure Disconnect Application Module Upon Release option is not set:
I have overriden VO method processChangeNotification for logging purposes, this method is invoked automatically for VO's set with AutoRefresh = true. No need to code anything here, I'm just logging method invocation:
Let's do a test. First of all, check entries of Job list:
Go to DB and update one of the entries. For example, change Stock Clerk title and commit changes:
Come back to UI and press any button. This will trigger new request and Jobs list shared VO will be notified about DB change to refresh:
Check the list again, you should see changed entry for Stock Clerk:
In the log we can observe a call for change notification, it triggers shared LOV query re-execution and data re-fetch:
See recorded demonstration video, where I show refresh behaviour live:
Make sure to remember to configure AM without disconnected mode. Auto refresh works for both application and session caching levels:
As a reminder - in order to use shared LOV functionality, you must select VO instance for LOV from shared AM configuration. See how it looks in the LOV definition wizard:
Auto refresh functionality is enabled with a single property - AutoRefresh = true. This can be set through VO general properties or directly in the VO source code:
Make sure Disconnect Application Module Upon Release option is not set:
I have overriden VO method processChangeNotification for logging purposes, this method is invoked automatically for VO's set with AutoRefresh = true. No need to code anything here, I'm just logging method invocation:
Let's do a test. First of all, check entries of Job list:
Go to DB and update one of the entries. For example, change Stock Clerk title and commit changes:
Come back to UI and press any button. This will trigger new request and Jobs list shared VO will be notified about DB change to refresh:
Check the list again, you should see changed entry for Stock Clerk:
In the log we can observe a call for change notification, it triggers shared LOV query re-execution and data re-fetch:
See recorded demonstration video, where I show refresh behaviour live:
Download sample application - ADFBCSharedSessionLOVApp.zip.
We have 500+ LOVs in our application. Is it good to apply this pattern on all those LOVs? I was more concern about the performance of the application after applying this on all 500+ LOVs.
ReplyDeleteYou should use cached LOV's for static data only. In general to answer your question, I would need to review your application.
ReplyDeleteRegards,
Andrejus
Hi Andrejus
ReplyDeleteIs there any performance impact by granting change notification privilege to database user.
I am also looking for options to refresh view instances in shared application module, without the database user having notification privileges.
Well, I guess nothing comes for free :) Obviously DB will have more work to do. But in general, change notification is very scalable, we are using it in heavy load systems without scalability issues.
ReplyDeleteAndrejus