What if Persistent procedures are not delete?

[jhdz]

Hi All,

I would like to know if someone knows what would happen if a procedure is call by persistent procedures and this is not delete?

Would the server experience some hang up? (to much activity by users, )
Would it stops from doing the procedure if this has a lot of instances (from the persistent procedure) that are not used anymore?

The reason of this question is that on the client environment happens this things and the procedure works fine but somethings dont , so I do not know if this could be the source of it.

Best regards,

 

[GregTomkins]

Hmm, I bet you get different answers, but here is mine:

1. If you fail to delete a PP you will tie up a (usually small, but potentially large) amount of memory until the OS process terminates.

2. If you fail to delete a PP that was RUN PERSISTENT across the AppServer boundary ,that AppServer agent will be "tied up" (not available to other clients) forever.

#2 is an oversimplification, but basically true.

Incidentally, one of the ironic things about P4GL is that though in most ways it is soooo much easier to use than (say) Java and eliminates soooo many niggling details irrelevant to business programming, when it comes to garbage collection, it doesn't even try (in the case of PP's and many other cases). Unless this has been added in a recent release?

 

[TomBascom]

10.2 does indeed have garbage collection although it is limited to the new OO stuff at this point in time.

 

[jhdz]

Thanks so much for your answer I really appreciated, I would delete these persistent procedures for now on . And I hope that it would work on the client side . I would try now on the client side and post the result later .
thanks a lot again.

 

[tamhas]

The basic rule has always been, if you create it, you should delete it. Doing anything else is the road to trouble. This is true of procedures, temp-tables, PDS, widgets, whatever. If there is an instruction to delete it, then that instruction should always be used.

We now have a form of garbage collection for OO objects, but I wouldn't hold your breath on seeing this added for procedural objects. Even there, an object that creates a temp-table needs to delete the temp-table in the destructor for the cleanup to be complete when the object is deleted.

There are a few trick like widget pools to help out, but this still requires the consciousness to put things into pools and know when the pool will be deleted.

As for crossing the AppServer boundary, you should never be running anything persistent across that boundary, not just because you will lock up the agent if the client dies, but because you are locking the agent to the client during that series of operations. Figure out instead how to always make your AppServer calls be stateless and, if persistent procedures are needed on the AppServer side, run them from that side, not from the client.

 

[GregTomkins]

I agree completely. I would like to once again repeat my complaint that P4GL has no reliable way that I know of to see what stuff is currently occupying memory (as do all the more mainstream environments). There are many edge situations in P4GL where I don't feel 100% certain I know where and how something is going to be cleaned up, and a simple way to expose everything on whatever P4GL's version of a heap is would sure be nice.

 

[tamhas]

Tried the debugger?

For any given object type, it is fairly simple to walk the tree and show what is left.

 

[GregTomkins]

I think that's something you v10 people enjoy - us v9 people can only dream. Now you are going to accuse me of whining about stuff from old versions and I guess I'll admit you're right - I did not realize v10 had a debugger that did that - maybe someday