What can cause an out of scope temp-table instances to remain on the appserver? - Forum - OpenEdge Development - Progress Community

What can cause an out of scope temp-table instances to remain on the appserver?

 Forum

What can cause an out of scope temp-table instances to remain on the appserver?

  • 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? 

  • 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
     
    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.

    Jeff Ledbetter
    Product Architect | Roundtable Software

  • 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. :(  
  • 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
     
    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.

    Jeff Ledbetter
    Product Architect | Roundtable Software

  • 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

     
    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?
  • 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).

  • 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? 

  • That is correct.
     
    Jeff Ledbetter
    skype: jeff.ledbetter
     
    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.

    Jeff Ledbetter
    Product Architect | Roundtable Software

  • 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

  • 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.
     
  • 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.

  • 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/
     
  • Are there any other cases (not just temp-table) where the object creation is implicit and the resulting object is not affected by scoping?

  • 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.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

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