JDE Cache Design Pattern Question

BOster

BOster

Legendary Poster
When I have used jde cache in my applications I usually name it Bxxxxxxx_[Job Number], where Bxxxxxxx is the Business function name and [Job Number] is a unique number using the internal next number. When I do this the cache is unique for each call and if needed I simply pass around the job number to other BSFNs that access the cache. I also allways, at some point, destroy the cache with a jdeCacheTerminateAll call or make sure that the number of jdeCacheTerminate calls match the number of init calls.

The MBF design of using cache says you never destroy the cache, instead job number is used as a field in the cache and when you are done with the cache you clear the records using a jdeCacheDeleteAll using the job number index. In order to not destroy the cache the number of jdeCacheInitMultipleIndex calls must be at least 1 higher than the number of jdeCacheTerminate calls and jdeCacheTerminateAll is never called. So my understanding of the design pattern for MBFs (or any other bsfn that does not destroy the cache) is as follows:

BeginDoc Function
jdeCacheInitMultipleIndex

EditLine Function
jdeCacheInitMultipleIndex
[do stuff]
jdeCacheTerminate

EndDoc Function
jdeCacheInitMultipleIndex
[do stuff]
jdeCacheDeleteAll [using the job number index]
jdeCacheTerminate

Now to my question:

Since BeginDoc will be called multiple times the number of jdeCacheInitMultipleIndex calls will continue to grow in relation to the number of jdeCacheTerminate calls. Will this cause any kind of memory leak over time? I know there is an internal counter that increments everytime init is called and decremented every time Terminate is called but this counter will continue to increase every time BeginDoc is called. Is there a maximum that this counter can reach? What happens if it does? Is the design pattern I layed out above correct or is there some pattern that makes sure the number of init calls is only 1 higher than the number of terminate calls?
 
In general you must always match a TerminateCache with an InitCache.

The pattern you showed will result in a memory leak. The cache that is initialized in BeginDoc must be terminated.

jdeCacheDeleteAll only deletes the elements in the cache. The cache itself remains open (i.e. in use) until you call jdeCacheTerminate or jdeCacheTerminateAll on it.

What will happen in your pattern is that the cache will init up to 100 BeginDoc cache handles. Then your jde.log will start to fill up with error messages. JDE will not allow more than 100 cache handles to be open at once.

You should definitely correct this problem given the nature of hooking up your caches in the MBF.

HTH
 
The 100 handle limit you are talking about is the number of open cursors handles for a given cache, not the maximum number of init calls that can be made.

I haven't actually used that design pattern. Where I have used cache in the past I terminate it. But reading through the documentation and looking at some of the JDE code where cache is used, but never terminated such as the 42UI11 cache it appears that JDE does what I outlined.

Too me it would seem like it would create a memory leak, however, the documentation indicates if the cache all ready exists all that is done is a handle to the cache is returned and a counter is incrimented. For cache like the 42UI11 cache that is never terminated I am not sure how you would accomplish this w/o the design pattern outlined above.
 
Memory leak? JDE/Peoplesoft programmers? No way, those guys are too good at what they do to introduce any memory leaks in their designs ... <;)
 
You are right about the open cursors vs InitCache.

The reason I responded the way I did is that I presumed you were opening a cursor in your BeginDoc -- silly me.

I've written a Generic Cache using a business function that utilizes an object pattern over the cache API. The Generic Cache treats the cache as an object: it is constructed by specifying a DSTR, TBLE, or BSVW and a list of DD items that specify the index. Under the covers the code calls the InitCache and open cursor. When disposing I close the cursor and terminate the cache.

The great thing about the Generic Cache is that it can be entirely used from ER, it works on all server platforms, and it even has a browser over it.

JDE apps developers would love it.
 
Wow, that sounds pretty cool. Would be a very useful tool for developers that have need for temporary work tables but don't want to mess around with C.
 
Anyway that you might be able to make the Generic Cache code available to me/us? We are trying to determine the appropriate method for using cache and there are a number of examples in the E1 business functions, but the usage is not consistent. Thanks much.
 
Back
Top