Each ProcObject encapsulates one procedure running as persistent, single-run, or singleton on an AppServer. The ProcObject exposes all non-PRIVATE internal procedures and user-defined functions to the client that you do not explicitly omit in ProxyGen when you define the ProcObject.

A ProcObject shares a connection established by an associated AppObject. You can create the ProcObject using a class factory method on the AppObject or SubAppObject to which this procedure was added in ProxyGen.

When you call the ProcObject class factory method on the AppObject or SubAppObject, it creates the ProcObject on the client. If the ProcObject maps to a persistent procedure, the class factory method also executes the corresponding procedure on the AppServer. Any parameters required by this procedure are required as parameters on the class factory method. The ProcObject saves a handle to the persistent procedure for future calls to its internal procedures and functions and for releasing and disconnecting the object from the AppServer application.

If the ProcObject is a single-run or singleton procedure, the class factory method creates the ProcObject on the client and saves a handle to the procedure, but unlike persistent procedures, the class factory method does not execute the corresponding procedure on the AppServer. Single-run and singleton procedures are only instantiated when one of their internal procedures or user-defined functions are called.

For session-free applications, ProcObjects that encapsulate persistent procedures have limited utility and tend to interfere with session-free application performance. Part of the value of persistent procedures is that they provide a means to maintain run-time context between the client and AppServer. Much of the value from session-free application services is that AppServer resources are more readily available to serve client requests. However, a persistent procedure binds an AppServer resource to the client that instantiates the procedure until the client deletes the procedure. This ties up a physical connection and reduces the AppServer resources available for requests from other clients, which can in turn reduce apparent application performance across the client domain.

Therefore, Progress Software Corporation strongly recommends that you avoid the use of ProcObjects that encapsulate persistent procedures in session-free applications. As an alternative, consider using the single-run or singleton options.