For applications that do not need to maintain a persistent connection to a server, the server can automatically disconnect and reconnect between events and maintain a virtual connected state, without explicitly issuing disconnect and connect statements. This feature is known as passivating.
The passivation feature is not a candidate for use in an applications that maintain and depend on temporary data within their workspace on the server between calls because the disconnected agents are cleaned out and reused between virtual connects.
An application can only passivate after completing a statement request. For example, if an SQL SELECT statement is issued, the application cannot passivate until the transaction completes fetching to the end of the set or an EDAQUIT is submitted. An error occurs if the server passivates and the application is not in the proper state. For applications using the EDAPREPARE, passivating cannot take place unless an EDAXPREPARE is issued. Since prepares are stored on the server and passivating destroys the server resources, the prepare is no longer available when the application reconnects.
An application must issue an initial EDASET with the variable EDA_VAR_CAN-PASSIVE(160) with a 1 for Yes after the initial connect to signal that the application will later use the passivate feature. The application then signals the server to passivate through the EDASET variable, EDA_VAR_PASSIVE (159), with 1 for Yes and 0 for No at the appropriate time.
Note: Optimally, passivating should be used in conjunction with commit and rollback.
| iWay Software |