Java Caching for Oracle Applications 11i: Part 1

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: 

  1. JVMs talk to each other and send the updated object to the other JVMs
  2. 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  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:


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

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:
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.


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.





I'm following Vincent McBurney's advice today to comment more on other Oracle blogs...

You might like to take a look at Tangosol Coherence - after all, you just bought the company.

A touch of history: Oracle originally sponsored JSR-107 (JCache). The current spec lead is Cameron Purdy - the founder of (you've guessed) Tangosol. Tangosol has a great rep for really solid, distributed, manageable caching (I know, we used to compete against them) so you might like to explore a few synergies there.


Posted by Nigel Thomas on May 02, 2007 at 12:50 AM PDT #

Nigel,Thanks for the tip.&nbsp; We haven't had an opportunity to investigate Tangosol's technology yet, but I'm looking forward to seeing how this plays out in the near future.Regards,Steven

Posted by Steven Chan on May 02, 2007 at 02:54 AM PDT #

Hi Steven,
What kind of configurations need to taken care by administrator after applying java cache patches, do we have any metalink note.


Posted by Phani K on May 03, 2007 at 06:01 AM PDT #

Hello Phani,

You will need to review the README of the specific patches you are applying for any special instructions or post patch steps to take, but there are no generic special tasks for Java Caching patches in particular



Posted by Mike Shaw on May 03, 2007 at 07:51 PM PDT #

thanks mike for this article

Posted by Fadi Hasweh on May 13, 2007 at 07:12 PM PDT #

Hi Steve,

I am very much a novice at this level but we have a problem at my current client.

We have users that are having problems logging in and in some cases having sessions terminated by what looks like a caching issue on the JVM.

We have 3 web nodes with a single JVM on each, basically, over the course of an hour or so, the java cache on each node fills up and eventually causes the issues above.

Any ideas as to what could be causing this?



Posted by guest on June 06, 2013 at 06:04 AM PDT #

Hi, Paul,

I'm sorry to hear that you've encountered an issue with this.

We can provide general conceptual guidance here, but I'm afraid that this blog isn't the best place to get technical support for specific issues like the one that you're working through.

Your best bet would be to log a formal Service Request via My Oracle Support (formerly Metalink) to get one of our specialists engaged.

Please feel free to forward your Service Request number to me if it gets stuck in the support process for some reason.


Posted by Steven Chan on June 06, 2013 at 09:43 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed


« July 2016