Forcefully Executing a View Accessor

To execute view accessor 'brutally' whenever frameworks refers view accessor row set, add the following in your parent view object implementation class.

  @Override  
  protected ViewRowSetImpl createViewLinkAccessorRS(AssociationDefImpl   
  assocDef, ViewObjectImpl accessorVO, Row masterRow, Object[] values){  
   if ("<viewlink accessor attribute name>".equals(assocDef.getName())) {  
     accessorVO.clearCache();  
   }  
   return super.createViewLinkAccessorRS(assocDef, accessorVO, masterRow,  
                       values);  
 }  



Learn More ...

There are a lot more points like this. If  you are curious to learn the internals of the ADF Business Components and ADF Binding Layer,  the following book is for you - Oracle ADF Real World Developer’s Guide.
More details about this book can be found in this post- http://jobinesh.blogspot.in/2012/07/pre-order-your-copy-of-oracle-adf-real.html

Comments

florinmarcus said…
This brings up another topic, related with caching on both view or entity level: What is the life span of the cache: per ADF session, per http request, or per transaction?

Oracle doesn't make this clear on documentation, might be because they see it as implementation detail, not for developer concern. Still, it would be helpful to have an understanding of caching.

Thanks.
Jobinesh said…
I'll blog on it sometime next week
Nick said…
Hi Jobinesh,

what are some of the use cases that you might find this brute force execution of a View Accessor useful?
Jobinesh said…
Nick,
One use case is tree search - When you expand a parent node, application fails to refresh child nodes.
Interestingly, the above case may work sometimes in a non predicable way. Reason is WeakReference of the QueryCollection used for child rowset are garbage collected periodically(when GC runs) and that cause framework to requery child rowset. The code snippet in the blog post ensures child rowset refreshes whenever framework asks for it.
Nick said…
Thanks Jobinesh. Always very informative. :)

Disclaimer

The views expressed on this blog are my own and do not necessarily reflect the views of my employer.