Java Caching for Oracle Applications 11i

最新推荐文章于 2024-08-15 14:47:41 发布

Mathilda91

最新推荐文章于 2024-08-15 14:47:41 发布

阅读量130

点赞数

文章标签： java 数据库

原文链接：http://www.cnblogs.com/ebs-blog/archive/2011/09/05/2167214.html

版权

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.

mzJavaD1:

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.

mzJavaD2:

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:

- Newly added responsibility is not displayed until Apache is bounced, after applying ATG RUP3 or ATG RUP4 (Metalink Note 374309.1)

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.

mzJavaD1:

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: