What can cause an out of scope temp-table instances to remai

Posted by jquerijero on 11-May-2015 11:48

I'm trying to figure what should I be looking for to make sure that a static temp-table instance goes away.

So I have this;

RUN myproc.p (OUTPUT TABLE ttStatic) ON SERVER myAppServer. 

RUN listbuffernames.p () ON SERVER myAppServer. // just scans session buffer handle

For some reason, my listbuffernames.p is listing ttStatic as still available on the appserver. What construct/situation inside myproc.p would cause a static table to remain in the memory after it went out of scope? 

All Replies

Posted by Jeff Ledbetter on 11-May-2015 11:54

Is the output parameter on the server-side procedure TABLE or TABLE-HANDLE? If the latter, it must be explicitly deleted.
 
Jeff Ledbetter
skype: jeff.ledbetter
 
[collapse]
From: jquerijero [mailto:bounce-jquerijero@community.progress.com]
Sent: Monday, May 11, 2015 11:49 AM
To: TU.OE.Development@community.progress.com
Subject: [Technical Users - OE Development] What can cause an out of scope temp-table instances to remain on the appserver?
 
Thread created by jquerijero

I'm trying to figure what should I be looking for to make sure that a static temp-table instance goes away.

So I have this;

RUN myproc.p (OUTPUT TABLE ttStatic) ON SERVER myAppServer. 

RUN listbuffernames.p () ON SERVER myAppServer. // just scans session buffer handle

For some reason, my listbuffernames.p is listing ttStatic as still available on the appserver. What construct/situation would cause a static table to remain in the memory after it went out of scope? 

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

Posted by jquerijero on 11-May-2015 14:09

[quote user="Jeff Ledbetter"]

Is the output parameter on the server-side procedure TABLE or TABLE-HANDLE? If the latter, it must be explicitly deleted.
 
Jeff Ledbetter
skype: jeff.ledbetter
 
[/quote]
Thanks.
It was an "INPUT PARAMETER .. AS HANDLE" to one of my worker program (.p). I know it creates a copy when you pass the table as a handle, but it doesn't seem right that you have to manually add a code to clean the input parameter at the end of the worker program.
I'm going to test out INPUT-OUTPUT PARAMETER ... AS HANDLE, I hope it doesn't behave the same way because I have no idea how can you clean up something that you have to output. :(  

Posted by Jeff Ledbetter on 11-May-2015 14:13

Just add a FINALLY block with a DELETE OBJECT <myTableHandle>. Or, ensure you clean up prior to your RETURN.
 
The OE session populates the output value before the table-handle is deleted.  It seems odd, but that is how it works. J
 
Jeff Ledbetter
skype: jeff.ledbetter
 
[collapse]
From: jquerijero [mailto:bounce-jquerijero@community.progress.com]
Sent: Monday, May 11, 2015 2:10 PM
To: TU.OE.Development@community.progress.com
Subject: RE: [Technical Users - OE Development] What can cause an out of scope temp-table instances to remain on the appserver?
 
Reply by jquerijero
Jeff Ledbetter
Is the output parameter on the server-side procedure TABLE or TABLE-HANDLE? If the latter, it must be explicitly deleted.
 
Jeff Ledbetter
skype: jeff.ledbetter
 
Thanks.
It was an "INPUT PARAMETER .. AS HANDLE" to one of my worker program (.p). I know it creates a copy when you pass the table as a handle, but it doesn't seem right that you have to manually add a code to clean the input parameter at the end of the worker program.
I'm going to test out INPUT-OUTPUT PARAMETER ... AS HANDLE, I hope it doesn't behave the same way because I have no idea how can you clean up something that you have to output. :(  
Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

Posted by jquerijero on 11-May-2015 15:22

[quote user="Jeff Ledbetter"]

Just add a FINALLY block with a DELETE OBJECT <myTableHandle>. Or, ensure you clean up prior to your RETURN.
 
The OE session populates the output value before the table-handle is deleted.  It seems odd, but that is how it works. J
 
Jeff Ledbetter
skype: jeff.ledbetter
[/quote]
 
For chained OUTPUT or INPUT-OUTPUT (programA calls programB calls programC), do I need to clean inside every program or just the inner most program?

Posted by Peter Judge on 12-May-2015 07:48

You can explicitly delete a table- or dataset-handle on the APpServer and be sure that the contents will survive the trip back to the client - there's code that defers the delete until it's been handed back to the client. You can see that in the debugger and the log-mnanager (I believe) where the table is marked as "DELETE PENDING" .

Note that this behaviour is only for returning data across an AppServer boundary and it only works in the .P that was called (ie not further down the stack).

For the rest of the time (ie all other intra-client or intra-server calls) you should be passing references to temp-tables or dataset (to avoid deep copies).

Posted by jquerijero on 13-May-2015 12:39

[quote user="Peter Judge"]

You can explicitly delete a table- or dataset-handle on the APpServer and be sure that the contents will survive the trip back to the client - there's code that defers the delete until it's been handed back to the client. You can see that in the debugger and the log-mnanager (I believe) where the table is marked as "DELETE PENDING" .

Note that this behaviour is only for returning data across an AppServer boundary and it only works in the .P that was called (ie not further down the stack).

For the rest of the time (ie all other intra-client or intra-server calls) you should be passing references to temp-tables or dataset (to avoid deep copies).

[/quote]

Just to double check, is this only an issue when passing table handle and not when passing the static temp-table? 

Posted by Jeff Ledbetter on 13-May-2015 13:06

That is correct.
 
Jeff Ledbetter
skype: jeff.ledbetter
 
[collapse]
From: jquerijero [mailto:bounce-jquerijero@community.progress.com]
Sent: Wednesday, May 13, 2015 12:40 PM
To: TU.OE.Development@community.progress.com
Subject: RE: [Technical Users - OE Development] What can cause an out of scope temp-table instances to remain on the appserver?
 
Reply by jquerijero
Peter Judge
You can explicitly delete a table- or dataset-handle on the APpServer and be sure that the contents will survive the trip back to the client - there's code that defers the delete until it's been handed back to the client. You can see that in the debugger and the log-mnanager (I believe) where the table is marked as "DELETE PENDING" .
Note that this behaviour is only for returning data across an AppServer boundary and it only works in the .P that was called (ie not further down the stack).
For the rest of the time (ie all other intra-client or intra-server calls) you should be passing references to temp-tables or dataset (to avoid deep copies).

Just to double check, is this only an issue when passing table handle and not when passing the static temp-table? 

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

Posted by jquerijero on 28-Feb-2017 12:07

While diagnosing another mysterious lingering temp-table, I stumble upon this pattern;

ON CHOOSE OF someButton:

 DEF VAR hTemp AS HANDLE NO-UNDO.

 RUN someprogram.p (OUTPUT TABLE-HANDLE hTemp).

 RUN semeprocedure(INPUT TABLE-TANDLE hTemp). /* this internal procedure has code to delete input temp-table handle per earlier discussion, and it works as you stated */

 /* However in this scope itself, another copy is created. If I don't do this, a temp-table remains in the memory even after closing this window */

 IF VALID-HANDLE(hTemp) THEN

DO:

  DELETE OBJECT hTemp.

  hTemp = ?.

END.

END.

Maybe the pattern can be pared down. Is this expected?

[EDIT] changed temp-table to table-handle

Posted by Peter Judge on 28-Feb-2017 13:00

Temp-table and other handle-based structures are not automatically cleaned-up.
 
Also, when passing arguments using the TEMP-TABLE (-HANDLE) or DATASET (-HANDLE) you make a deep copy every time. That’ll leak.
 
In 11.0 there’s a new LOG-ENTRY-TYPE called TEMP-TABLES that   logs the creation and destruction of temp-tables and datasets.
 

Posted by jquerijero on 28-Feb-2017 14:00

So we need to clean up sometime in the code if we use something like this?

DEF VAR hTemp AS HANDLE NO-UNDO.

RUN someprogram.p (OUTPUT TABLE-HANDLE hTemp).

My original understanding is that I only need to clean up inside someprogram.p.

Posted by Peter Judge on 01-Mar-2017 08:54

Yes. Clean up or  use the BY-REFERENCE qualifier on the call. That makes the call a reference / pointer rather than by value.
 
There are a couple of references to it in a session Paul Koufalis and I did at the PUG Challenge. Slides 29 and on at onedrive.live.com/
 

Posted by jquerijero on 01-Mar-2017 09:14

Are there any other cases (not just temp-table) where the object creation is implicit and the resulting object is not affected by scoping?

Posted by Mike Fechner on 01-Mar-2017 09:25

A CATCH Block in 10.1C left oyu in charge with deleting the error object. 10.2A introducted the GC for class based objects to fix that.

Posted by jquerijero on 03-Mar-2017 16:02

Is this only a problem with table-handle and dataset-handle, or is this an issue with handle data-type in general?

Posted by jquerijero on 15-Nov-2017 12:01

Bump. Just trying to make sure if I have to watch out for this behavior when passing widget handle and other types of handles.

Posted by Brian K. Maher on 15-Nov-2017 12:04

Not cleaning up dynamic temp-tables is one cause.

Posted by jquerijero on 16-Nov-2017 09:53

Brian,

Can you verify if this behavior affects any handle-type parameter or just temp-table and dataset handle?

Posted by Brian K. Maher on 16-Nov-2017 09:58

It may be possible.
 
Use the code in this KB ... knowledgebase.progress.com/.../P124514
 
and turn on DynObjects.Other logging

This thread is closed