[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: Garbage collection for the sake of static temp-tables (in long-running _progres)

Status
Not open for further replies.
D

dbeavon

Guest
Thanks for the feedback guys. The code I posted was fairly complete. Assuming the last snippet above is put in a program called dkb/ReproBug/SeedLogicWorker.p, you just need to run it repeatedly like so. DO WHILE TRUE: RUN dkb/ReproBug/SeedLogicWorker.p. END. This type of loop might exist in a long-running background process or such. You will see that this program (SeedLogicWorker.p) creates new static temp-tables, and they are leaked rapidly ... resulting in a SYSTEM ERROR about too many indexes. >> As the class instance is not the "owner" of the dataset/temp-table the GC will not clean that up when your object instance is GC'ed. Yes, I know that the class is not the owner. That was deliberate. This is a logic class, and doesn't actually own the data, but operates on data from a client. I want the class instance to hold loosely to the table until the work is done, and the instance dies. When the work is done and the instance dies, I'd like it to be GC'ed and for the static temp-table data to be released as well. The only two things that are actually "pinning" the static temp-table are : (1) the instance of the class and (2) the calling program (SeedLogicWorker.p). So how can I put a pause statement or something in the code or something, to encourage GC (assuming that is possible in _progress processes)? Any tips would be appreciated. I was surprised that the problem is so easy to create. It is a basic static temp-table and a basic OOABL class. I can do my best to avoid the SYSTEM ERROR by using "DELETE OBJECT" statements, but would prefer not to clutter code with FINALLY blocks that do nothing more than what the GC should already be handling for me.

Continue reading...
 
Status
Not open for further replies.
Top