Purpose of Entity / View caches

Question

From research, articles, testing, and what info I've been able to glean off forum and metalink, it appears that entity/view caches are not used to satisfy querying, but to minimize storage of redundant data in memory. In other words, the purpose of the cache is simply to minimize memory used, but does not help query performance in any way.
Is this accurate? If this is the case, it would seem that minimizing caching in many cases might be better for performance than using a cache.
I've asked about the naure of entity / view caching in a TAR -- over two weeks in, still no answer....
B

Answer 1

Brad,
A fundamental design point of ADF Business Components is that we let the database be our global, cross-user shared cache. We make no attempt to try and be the global, shared cache in the middle tier very much by design. The application module defines the boundaries of the current users unit of work, and provides facilities for allowing that unit of work to span multiple HTTP requests with failover protection, etc.
The alternative approach is to try and provide a global, shared cache in the middle-tier, and require the user to consciously clone objects that need to be modified, and then deal with the issues of keeping the global, shared cache up to date when users make changes. This incurs overhead to maintain the consistency of that global cache when users are pounding lots of changes into it. We consciously opted against this approach after studying the way that Oracle Applications applications worked with the database in a typical scenario. The AM's transaction, which holds the caches, is a cache of in-progress work by that user, which can optionally have some of its data kept around for the next client that will use that AM from the pool.
The AM instances are pooled and used in a stateless way, but using an algorithm called "stateless with affinity" which attempts to keep an AM intance "sticky" to the client that used it last if load allows us to do that. This occurs when the user is performing a unit of work that spans pages, so that the AM is being released to the AM pool in the "Managed State" mode instead of the "Stateless" mode.
During the span of that unit of work, a user might use the same LOV's and visit the same screens over and over in the act of completing the job. The caches allow that user to avoid requerying any of that data during the span of that transaction, and generally the caches will contain only the data that is relevant to that user's task at hand.
In 10.1.2, you can use the RowQualifier to filter rows in memory for simple kinds of SQL-type predicates. In 10.1.3, we've added a lot more control for querying over the caches, filtering over the caches, and doing both -- under developer control -- over either or both the cache and the database.
Today, the primary way that the cache comes into play is avoiding database queries when things like association traversal is performed (typically as a part of business logic inside entity objects that need to access related entities to consult properties or methods on them), finding an entity by primary key which is performed for various reasons I've outlined in this blog article...
http://radio.weblogs.com/0118231/stories/2005/07/28/differenceBetweenViewObjectSelectAndEntityDoselectMethod.html
..., as well as avoiding requerying when you re-render view object data that's already been queried during the unit of work.
The entity cache holds the entity instances that the user has queried into the application module instance's transaction. The entity cache is populated by virtue of a view object's SQL statement, or by a direct or indirect call to EntityDefImpl.findByPrimaryKey().
That said, we do support the notion of a shared, read-mostly application module as well. To use a shared application module, you need to set the jbo.ampool.isuseexclusive configuration property to the value false.
Since all users are sharing the same application module, in particular they are sharing the view object instance, and even more in particular, its default rowset's default iterator.
At the present time, for this feature to work robustly, the client code must insure that each user iterating the rows in a view objects inside a shared AM instance creates his own RowSetIterator and does not rely upon using the default RowSetIterator. Failure to do this could result in users messing each other notion of "current row" up.
If you read my article on OTN about VO Performance Tuning...
http://www.oracle.com/technology/products/jdev/tips/muench/voperftips/index.html
you'll see that by avoiding caching when not needed, in some situations you can improve performance.
We hope to make the multi-user, shared-readonly data reading even simpler to take advantage of in the future for shared, read-only data, but it's possible to achieve today with a little work.