JDEDEBUG.LOG and table I/O - subsystems, is the table cached or not?

[johndanter]

Hi folks

I have an interesting question on database tables set up for caching in P98613 and subsystems.

Am I right in thinking when a subsystem is first launched it creates it's table database cache based on what tables were setup for caching at the time the UBE first runs....?

Am I also right in thinking, asking CNC to reset database cache does nothing to affect what the SBS is holding in it's cache?

Second question: Am I right in thinking UBEs spawned from a Subsystem share the same cache as the calling subsystem?

The SBS goes on to call downstream UBEs and the problem in the downstream UBEs, not the SBS.

The issue I have is F0010 and subsystems. I want to make sure the SBS inherits the correct fiscal period and doesn't 'stick' with what it was when it first launched.
We reset every SBS' every 1st Thursday
The Finance team only nudge the fiscal period on on day 6 of the month. Then tell CNC to refresh the cache.

I am worried the 2 maybe out of whack until the SBS is restarted.

Is there an indication in the debuglog that a select statement came from cache or the DB proper? Or is it just check P98613?

Thanks

John

 

[altquark]

I don't believe this is correct. Every time a UBE is run, it needs the information for the user specifically running the job. So it reads the system tables and re-caches at the time the UBE is run. You should be able to see in a JDEDEBUG.LOG for any process run where it is actually "caching" the information right at the very beginning of the process. If its retrieving F00950 records, for example, then its reading everything right at that point in time. So a UBE does that right at the beginning for EVERY UBE launched. Then, once it has it read, it has it cached, and the rest of the time the UBE runs, it goes to cache instead of to the DB.

 

[johndanter]

Ok but it doesn't explain to me why this all worked when I restarted the subsystem. Plus I am only referring to tables setup for caching mind.So maybe the user ID table isn't setup like that. F0005 F0010 are.

No code change, no UDC change, no config change, just a restart and it worked. Which suggests to me that the subsystem is caching values it had when it launched.

FYI the subsystem actually calls secondary UBEs. The issue is in the secondary UBEs

My log has no mention of F00950, but I can't find any in my manual submission either.

Plus I since found this
E1: ENV: Frequently Asked Questions on Caching in EnterpriseOne (Doc ID 944015.1)
Q18. Is there a way to force subsystem process/jobs to pick up changes to UDCs that occurred since the
subsystem UBE was first submitted?
No. Due to the nature of subsystem UBEs, these run continuously and by default. So changes to UDC values will not be picked
up until EnterpriseOne services are restarted, or the subsystem UBE is stopped and restarted. Refer section "When is the JDB
Database Cache Used?" which explains why it performs dirty read.

 

[Larry_Jones]

Better to just remove F0010 from the database Cache list if you're pre 9.1.
We did that and ran for years that way.
Under 9.1 and higher JDE cache for F0010 is automatically updated/refreshed when changes occur.

 

[johndanter]

Hi Larry

That has been my suggestion to them yes. Remove F0010