Can you call something that is non-interactive that will clean out any globals in ^CacheTempUser.* ?

Question

Question

Stephen Wilson · Sep 6, 2017

These Globals are usually cleared out as part of the startup/shutdown processes. If your server never reboots how would you clean these out?

Discussion (5)0

Log in or sign up to continue

Alexey Maslov · Sep 6, 2017

We have a TASKMGR's task that purges such kind of globals daily. (Sub)globals are cleaned using the following criteria:

Global has a structure of @name@(PID)
Global is listed in predefined "known globals" list
Caché process identified with PID is not running.

2 0

score 2 · Answer 1 · 2017-09-06T09:32:56-04:00

Robert,

You are quite right, but... life is life, and application can finish abnormally. In this case its temp globals are left till Caché restart, sometimes it may cause noticeable growth of CACHETEMP database. So, scheduling a nightly housekeeping task like ours makes some sense.

score 1 · Answer 2 · 2017-09-06T08:21:12-04:00

It's the task of the application that uses ^CacheTempUser.* to take care of the housekeeping.
I found no traces that it belongs to Caché System Management and Operation.

score 2 · Answer 3 · 2017-09-06T08:56:57-04:00

of course it makes sense!

but then you know which application is using it and can use the application's cleaning method / routine that takes care of all kind of dependencies:
I remember well times when routines used to start with KILL ^CacheTemp*($JOB)
I expected over time most applications are using PPG (^||myGlobal...) to avoid this. Or have a Clean-Up.

score 2 · Answer 4 · 2017-09-06T09:56:30-04:00

I remember well times when routines used to start with KILL ^CacheTemp*($JOB)

Our developers do the same, but modern versions of OSs usually have 6 digit PIDs, so it may take several days till PIDs would re-cycle their numbers.

PPGs are used, however sometimes they are not applicable, e.g. when information is passed between processes via temp globals.

Clean-up is a good idea, but can be fully implemented when (and only when) all app classes use the same before-exit-processing code, i.e. the app is always finish through one exit point. Sometimes it's difficult to achieve, while it's worth to.

A while ago I thought about some enhancements of my purging task:

automatic detection of too quick growing globals
automatic detection of globals which belong to its scope, i.e. have @name@(PID) format.

Maybe I do it when have some spare time... the priority of this work is rather medium.