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

[dbeavon]

I was wondering how to read this KB. Progress KB - How to force application garbage collection? The only specific place where ABL garbage collection is forced to happen is on return from an AppServer call (deactivate procedure) Is it saying that there is no ABL garbage collection except in appserver? Or is it saying that appserver *forces* GC, but other types of clients (like _progres) will perform GC on occasion but it cannot be forced. I have class that takes a reference to a static temp-table and BIND's to it: USING Progress.Lang.*. BLOCK-LEVEL ON ERROR UNDO, THROW. Class dkb.ReproBug.SeededDocumentLogic: {dkb/ReproBug/Data/LocalSalesTransData.i REFERENCE-ONLY PRIVATE} CONSTRUCTOR PUBLIC SeededDocumentLogic ( INPUT-OUTPUT DATASET FOR DS_LocalSalesTrans BIND): SUPER (). END CONSTRUCTOR. END Class. The include dkb/ReproBug/Data/LocalSalesTransData.i is like so: /* ************************************************************************ */ /* Intial data */ /* ************************************************************************ */ DEFINE {2} TEMP-TABLE LL{3}_sls_trans NO-UNDO {1} FIELD Field1 AS CHARACTER FIELD Field2 AS CHARACTER FIELD Field3 AS CHARACTER INDEX LL_sls_trans_01 IS PRIMARY UNIQUE Field1 Field2 Field3 INDEX LL_sls_trans_02 Field2 INDEX LL_sls_trans_03 Field3. /* ************************************************************************ */ /* The dataset with the local/session data that we care about. */ /* ************************************************************************ */ DEFINE {2} DATASET DS{3}_LocalSalesTrans {1} FOR LL{3}_sls_trans. I use this class in logic loops like so, and don't always run DELETE OBJECT (eg. in the case of unexpected errors). /* ************************************************************************ */ /* LL_sls_trans - used for composing the data */ /* ************************************************************************ */ {dkb/ReproBug/Data/LocalSalesTransData.i} /* ************************************************************************ */ /* Operation vars */ /* ************************************************************************ */ DEFINE VARIABLE v_DocLogic AS dkb.ReproBug.SeededDocumentLogic NO-UNDO. /* ************************************************************************ */ /* Do logic in a loop. */ /* ************************************************************************ */ DEFINE VARIABLE v_Loop AS INTEGER NO-UNDO. DO v_Loop = 1 TO 5: /* ************************************************************************ */ /* Output for this invoice */ /* ************************************************************************ */ EMPTY TEMP-TABLE LL_sls_trans. /* ********************************************************************* */ /* SEEMS TO CREATE LEAKS */ /* ********************************************************************* */ v_DocLogic = NEW dkb.ReproBug.SeededDocumentLogic(INPUT-OUTPUT DATASET DS_LocalSalesTrans BIND). /* DO WORK HERE */ /* Clean up Doc Logic DELETE OBJECT v_DocLogic.*/ END. Unfortunately I find that my static temp-tables "leak" as a result of the reference that is made by the OOABL class. The error I eventually get is: SYSTEM ERROR: Attempt to define too many indexes for area 6 database DBI11996a17396. (40) (14675) I'm assuming the OOABL class instances are leaking too, but the problem doesn't expose itself as severely as the temp-tables that are leaked at the same time. I'm wondering what I need to do to avoid the leaking of static temp-tables. Is there a way to ensure that GC will run at some point to release the "leaked" temp-tables? Can I put a pause statement in the code or something, to encourage GC? Any tips would be appreciated.

Continue reading...