Java Caching for Oracle Applications 11i
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:
- Disk Cache
- CPU Cache
- Web Cache
- Oracle Database Buffer Cache of the SGA
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 Caching
Java 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 Caching
There 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)
eBiz leverages Java Caching mechanism implemented by the iAS Technology itself. It is sometimes required to apply iAS Technology patches for Oracle9i Application Server 1.0.2.2.2. You should only apply patches that are released by the eBiz Applications Technology Group (ATG) team.
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)
Updates to these packages are shipped via normal Apps patches. Originally released via JTT product patchsets, these patches are now rolled into FND patchsets such as ATG RUP4. The eBiz ATG development team is responsible for this layer.
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 11.5.10.3RUP"
- Patch 5468797 "CACHE INVALIDATION CONSOLIDATED PATH POST CU3"
Functional layer
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
Java Caching uses a separate set of port numbers for communication between JVMs. These ports need to be opened through a firewall for Java Caching to function. These ports are defined by the following profile options:
- FND_CACHE_PORT_RANGE
- JTF_DIST_CACHE_PORT
These profile options are configured in AutoConfig via these CONTEXT.xml file variables:
- s_fnd_cache_port_range
- s_java_object_cache_port
Run the Java Cache Diagnostic Tests
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
Review the javacache.log
This log file is located in $COMMON_TOP/rgf/<Instance >_<Hostname> and provides error messages specific to Java Caching.
Conclusion
Java 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.
In my previous article "Java Caching for Oracle Applications 11i: Part 1" I talked about the basics of Java Caching and how it works conceptually.
My original intention with "Part 2" was to discuss how to diagnose issues with Java Caching, but I got a bit carried away with scripts and the like so ended up creating some Metalink notes instead.
Diagnosing Database Invalidation Issues
Here's the first one:
- Diagnosing database invalidation issues with Java Cache for eBusiness Suite (Metalink Note 455194.1)
As it says on the tin, this note covers diagnosing issues with Database Invalidation. The classic symptoms being that when Responsibilities are added to a user, they are not appearing immediately (but do after Apache is bounced).
Although the scripts are listed in the note, you can also download a soft copy via the link mentioned in the note.
Diagnosing Issues with Responsibility Assignments
This issue is not actually a Java Caching problem, but the symptoms
initially look similar to those described above. The key difference
here is that the affected responsibilities still do not appear after
Apache is bounced. For details, see:
- Existing Responsibility Does Not Appear after modifying the effective date (Metalink Note 458869.1)
More on NoClassDefFoundErrors
This one seems to be a bit of a "phantom illness" as I have seen two
or three customers hit this issue, but after following the Action Plan
in the note the problem is not reproducible anymore. Even more
bizarrely, after reverting the changes introduced by the Action Plan,
the problem doesn't come back! This one has piqued my interest, so
if anyone out there has the same symptoms and can still reproduce the
problem after reading the following note, then I would be happy for you to
email me your SR number.
- Investigating NoClassDefFoundError in eBusiness 11i when users login (Metalink Note 455366.1)
Hopefully you will find these notes useful towards understanding and diagnosing any Java Cache issues you find yourself facing.
Related
- Java Caching for Oracle Applications 11i: Part 1
- Latest JVM Tuning Recommendations for Apps 11i
- Using JConsole to monitor Apps 11i JVMs
- Investigating java.lang.OutOfMemoryError with Apps 11i Middle Tier JVMs
see:http://blogs.oracle.com/stevenChan/entry/java_caching_for_oracle_applic_1