Java Caching for Oracle Applications 11i: Part 1
By mzshaw on May 01, 2007
In this article I will try to explain some of the mysteries around the "Java Caching Framework," as this is a commonly misunderstood technology (which is probably due to it being well-hidden from the casual observers view).
This article will be an introduction to the topic, rather than trying to talk about all aspects. I intend to write a follow up article to talk in more detail about common issues, configuration and troubleshooting for Java Caching, but let's start with the basics...
What is a Cache?
In general computing terms a cache is simply a copy of some data, sometimes prefetched or perhaps precalculated data, stored away from the original data. The purpose of the cache is to provide faster access to data, as it will be stored either closer to the user and/or in a faster access medium.There are a multitude of caches, some which have been around since computing began. To name a few that immediately spring to mind:
What is eBiz Java Caching?
Data from the eBiz database is stored (cached) in the OACoreGroup Java Virtual Memory (JVM) memory on the eBiz Middle Tier server. Normally this is done only when data is first accessed by the JVM, although the technology allows data to be preloaded if the Developer chooses.
It is also important to remember that every OACoreGroup JVM has its own local Java Cache, separate from the others. We'll talk more about that later in this article.
Why Use Java Caching?Java caching improves Application performance because data is retrieved from JVM memory. This saves a network trip to the database, and in turn saves the time taken for a SQL command to extract data.
Characteristics of data that is most suitable to be cached:
- Expensive SQL query
- Does not change very often
- Is frequently used
Challenges of Distributed Caching
Oracle E-Business uses the DISTRIBUTED cache model, where updates to objects in one JVM are propagated through to other JVMs using the same database. If you have multiple eBiz middle tier servers and/or multiple OACoreGroup JVMs configured, there needs to be a mechanism to keep these separate JVM Java Caches synchronized. A developer must specify which of the following two synchronization methods to use:
- JVMs talk to each other and send the updated object to the other JVMs
- A JVM will just send an invalidation message for a specified object. This is more commonly used.
An additional consideration is how to handle updates to data that happens outside of the JVMs, such as with updates via the Forms interface or a batch process. For this case, an invalidation business event is triggered from the database, sending the JVMs an invalidation message for any records that have been updated.
If an object is invalidated in a JVM, it will be reread from the database when next accessed. The new version will then be stored in the JVM's cache.
A Brief History of Java CachingJava Caching has been around in the E-Business Suite for quite a long time. It was not used by many Apps products until 11.5.10, as this was the first release where Database Invalidation was introduced. I believe iStore was the first team to utilize Java Caching functionality in any depth. Since 11.5.10 CU2, more and more product teams are using Java Caching.
Understanding How to Patch Java CachingThere are several different dependent layers to Java Caching, which is implemented as Java Classes stored on the Apps Web Tier:
Application Server packages (oracle.ias.cache)
At the time of writing, the latest patch for this layer is:
- Patch 5639951 "REHOST ORACLE JAVA OBJECT CACHE (FORMERLY OCS4J) FOR ORACLE APPLICATIONS 11i"
JTF and FND packages (oracle.apps.jtf.cache and oracle.apps.fnd.cache)
At the time of writing, two patches are recommended on top of ATG RUP3 and ATG RUP4
- Patch 5455628 "CACHE DIAGNOSTIC ARU ON TOP OF 18.104.22.168RUP"
- Patch 5468797 "CACHE INVALIDATION CONSOLIDATED PATH POST CU3"
It is up to the individual Applications product teams to utilise the Java Caching Framework provided by ATG. Product teams are responsible for creating and maintaining their own "buckets" (more properly called a "Component Cache") within the Java Cache, and to control the invalidation mechanism for their own objects.
Updates to code on this layer are released via product-specific patches. Unfortunately, a list of product-specific patches is beyond the scope of this article.
Troubleshooting Common Problems
Updates to data not being shown immediately
A commonly reported symptom is that changes to users' responsibilities are not taking effect immediately. Customers report this problem after applying the ATG RUP3 patch. The Applications Technology Group implemented Java Caching for responsibilities (amongst other things) in ATG RUP3, so this is often the first time customers see Java Caching in action (or perhaps I should say "inaction" in this case).
If you're encountering this behavior, the following Note should help:
Java Caching through a firewall
If you are experiencing any symptoms that could be attributed to Java Cache problems, it is important to gather the information from the Diagnostic Tests. For example, one test will prove if database invalidation is functioning correctly.
These tests were introduced in JTT.E (11.5.10) and can be accessed via the "CRM HTML Administration" responsibility:
- Diagnostics--> CRM Foundation--> Caching Framework
This log file is located in $COMMON_TOP/rgf/<Instance >_<Hostname> and provides error messages specific to Java Caching.
ConclusionJava Caching is simple in concept but can be complex to troubleshoot. This article has hopefully given you some insight into the fundamental concepts. We'll delve deeper into some of these concepts in my next article.
- Newly added responsibility is not displayed until Apache is bounced, after applying ATG RUP3 or ATG RUP4 (Metalink Note 374309.1)
- Oracle Applications Java Caching Framework Developer's Guide, Release 11.5.10 (Metalink Note 275879.1)
- Latest JVM Tuning Recommendations for Apps 11i
- Latest E-Business Suite Technology Stack (ATG RUP 4) Now Available