Kbase P123611: How to decide between Persistent or Not Persistent procedures in AppServer
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
22/06/2007 |
|
Status: Unverified
GOAL:
How to decide between Persistent or Not Persistent procedures in Application Server
GOAL:
How to decide between Temp-tables or XML as parameter to Application Server
FACT(s) (Environment):
All Supported Operating Systems
OpenEdge 10.x
FIX:
When creating proxies to access 4GL code from other languages, Progress provides option to use persistent or standard procedures, and it is a tradeoff between performance, scalability, and design of the application choosing the best option.
Scalability is something to think about because a persistent procedure requires the client to stay connected to the Application Server while calling methods (internal procedures) on the procedure object. It may be the case client connects, calls a method and takes a long time to disconnect or call another method, and for all this time, the Agent is going to be tied up to the client. However, the application design may require the use of internal procedures, due the fact that they can preserve state between calls.
Performance is another point to think about, although there are no BIG differences from calling persistent or standard procedures. If the application does not have big .r files, and use -q parameter, using standard procedures may be slightly faster, because there is no overhead to manage procedures handles. Moreover, the -q parameter tries to keep previously loaded .r code in memory for the next execution and speed up the process.
Another thing to consider when exposing methods is how to pass temp-tables from a external client to Application Server. Progress allows you to receive a temp-table ready to use or a XML and convert it to the temp-tables inside Progress. Choosing the best choice could be trick, and depends on the volume of data client sends to the server, and how complex are those data structured as well how frequently that structure changes. If the data structure is already mature and not subject to frequent changes, the client application could take the advantage of decreasing network traffic to send temp-tables to server instead of sending XML. Remember that XML is a String for practical purposes and has lots of repeated information about the data structure, like name of tags, comments, or even unnecessary information. Also consider effort in the client application to create the appropriated objects to represent a temp-table, as well the effort in the server to convert the XML to temp-tables. Java and .net may offers more parses based in Sax and DOM, and is easier to find a Java/.net Programmer who manipulates well XML then a 4GL one that knows lots of things about XML.