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

[Mike Fechner]

ABL GC will be performed by any other session type as well. It's not specific to the AppServer. As the K-Base article states the ABL GC is (unlike in .NET) almost everytime executed synchronously. The AppServer deactivate seems to be slightly special as GB seems to be enforced here. As to my experience the ABL GC always ever - in it's current implementation - works synchronously I doubt that the special GC activation during the AppServer deactivate event every has to do anything. The class you have posted here defines a REFERENCE-ONLY dataset/temp-table. That means the temp-table schema is only provided in the source code (include file) so that the compiler can perform strong typed checks against the fields and tables. When your class is executed it won't create an instance of the dataset and temp-table. It will bind to a dataset/temp-table instance you are providing as an argument to the constructor. 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. When you experience leaking of that temp-table (and finally too many TT indexes in the temp-table database file), this must be coming from the procedure that contains your temp-table definition without the REFERENCE-ONLY keyword and thus creates the instance of the temp-table. Persistent procedures on the other end are like dynamic buffer object handles, query object handles, etc. considered "handle based objects" in the language. The GC only works for "class based objects". Without knowing more about your code, I would assume, that the leak comes form a persistent procedure that defines the temp-table and is not properly cleaned up. You could also loop through the SESSION:FIRST-OBJECT chain (and then the object's NEXT-SIBLING) to gain insights into loaded object instances. I sometimes use code like this: DEFINE VARIABLE o AS Progress.Lang.Object NO-UNDO. o = SESSION:FIRST-OBJECT. DO WHILE VALID-OBJECT (o): LOG-MANAGER:WRITE-MESSAGE (SUBSTITUTE ("&1 &2", o:GetClass():TypeName, o:ToString())). o = o:NEXT-SIBLING. END. A similar loop can be coded based on the SESSION:FIRST-PROCEDURE handle.

Continue reading...