RealHeavyDude
Well-Known Member
The SESSION:FIRST-XYZ is the way to go. For AppServer logic in my test environment I have a procedure which sole purpose is to generate a report about all dynamic handle based objects available in the session. When testing my logic for debugging I always run that procedure in advance of the actual procedure call and immediately afterwards. That way I am able to see if something is "hanging about" in the AppServer agent's session which should me there and also if my logic has cleaned up properly.
For the most part we use generic entry points on the AppServer that accept or return dynamic ProDataSets which then, depending on the context, instantiates the specially purposed classes for the specific business objects. Inside this classes we are all static. So, when the static ProDataSet from the specially purposed class is returned to the generic entry point procedure which expects a DATASET-HANDLE the dynamic object for that is implicitly created and we needed to take care about it in removing it at the end of the main block. As we use that DATASET-HANDLE as output parameter we found out that the AVM postpones the delete until the ProDataSet has been passed out. It works perfectly but you need to figure that one out. I did not notice that the memory consumption of the AppServer agent increased with each consecutive call but I had no idea as to why until I implemented that debugging to find out why. Since that time I would never run any procedure on the AppServer without debugging the dynamic objects existing in the memory of the AppServer. As most likely this will be a stateless or state-free environment you need to have an AppServer which can only spawn one agent in order to make sure you always end up on the same agent without binding an agent.
Heavy Regards, RealHeavyDude.
For the most part we use generic entry points on the AppServer that accept or return dynamic ProDataSets which then, depending on the context, instantiates the specially purposed classes for the specific business objects. Inside this classes we are all static. So, when the static ProDataSet from the specially purposed class is returned to the generic entry point procedure which expects a DATASET-HANDLE the dynamic object for that is implicitly created and we needed to take care about it in removing it at the end of the main block. As we use that DATASET-HANDLE as output parameter we found out that the AVM postpones the delete until the ProDataSet has been passed out. It works perfectly but you need to figure that one out. I did not notice that the memory consumption of the AppServer agent increased with each consecutive call but I had no idea as to why until I implemented that debugging to find out why. Since that time I would never run any procedure on the AppServer without debugging the dynamic objects existing in the memory of the AppServer. As most likely this will be a stateless or state-free environment you need to have an AppServer which can only spawn one agent in order to make sure you always end up on the same agent without binding an agent.
Heavy Regards, RealHeavyDude.