Problem using BSFN B4900191 - Cache Process Routing Options

Hi,

We're working on a specific batch to answer a customer need.

This batch uses the BSFN B4900191 - Cache Process Routing Options.

Simple test runs were OK. But our customer launched the batch to process a lot of data.

He sent us back an email saying that some of the final (expected) data were missing.
After going throught the log, we found A LOT of " CAC0001017 - (jdeCacheOpenCursor) Attempt to exceed total number of simultaneously open cursors (100) per cache failed"

We went deeper into the batch code and I noticed the following sequence in the Do Section of the batch.


Get a JOBS Number (let's call it va_JOBS)
[...]
Route Shipments(va_JOBS)
Cache Process Routing Options(va_JOBS)
[...]
While conditions
Cache Process Routing Options(va_JOBS)
End while
[...]
If anotherCondition
Clear Routing Cache(va_JOBS)
Stop Event
End If
[...]
Update Shipment Routing(va_JOBS)
Clear Routing Cache(va_JOBS)


Something in here is reaching the "total number of simultaneously open cursors".

First guess: the while loop.
I tried with some random data and manage easily to reach ~80 loops.
So maybe our customer used some datas and went over 100 iterations ...

Second guess, more a question: If I'm using the BSFN Cache Process Routing Options with the same JOBS number several times.

Cache Process Routing Options(1)
Cache Process Routing Options(1)
Cache Process Routing Options(1)
Cache Process Routing Options(1)
[...]
Cache Process Routing Options(1)

Will a unique Clear Routing Cache(1) release the whole cache ?
Or do we need to do 1 Cache Process Routing Options => 1 Clear Routing Cache ?

If I do 10 Cache Process Routing Options(1), 70 Cache Process Routing Options(2) and 40 Cache Process Routing Options(3), does the 10+70+40 (>100) count as a 100-cache-barrier-breach ?
Or does this 100 limit applies only for a cache operation on a specific va_JOBS ?

I'm working on Xe SP23

Thanks in advance.

Hello

I have used some of Advanced Transportation Management system’s caches functions. I think that they manage memory very well. They close cache cursor most of the cache operations except for CACHE_GET_NEXT. I believe that B4900191 will not close a cache cursor when B4900191 is called with the cache action of “6” and B4900191 finds a matching key record in the cache. I believe that B4900191 will close a cache cursor if jdeCacheFetchPosition fails with the cache action code of “6”. It means that B4900191 did not find a matching key record in the cache.

I do not know the conditions for the while loop in your UBE. You may need to close a cache cursor if you need to exit the loop before it reaches the end of the cache. If you exit the loop because you found a desired route, I believe that you need to close the cache cursor at that point.

We use 910 and jdedebug.log in 910 will show the number of cursor opened.

Open Cursor Success - hCursor:[240A02B0] hCache:[0CC00700]
Feb 27 09:41:49.021028 - 35824/8100 WRK:Starting jdeCallObject hCache:[0CC00700] Nm:[1B5841001F-2] Recs:13 Curs:1 Hnds:14 Cchs:5 CURS open
Feb 27 09:41:49.021029 - 35824/8100 WRK:Starting jdeCallObject Entering jdeCacheAdd
Feb 27 09:41:49.021030 - 35824/8100 WRK:Starting jdeCallObject hCache:[0CC00700] Nm:[1B5841001F-2] Recs:14 Curs:1 Hnds:14 Cchs:5 ADD