Data Module Lifetime Management
Go Up to The Structure of the Application Server
Object pooling allows you to create a cache of data modules that are shared by their clients, thereby conserving resources. How this works depends on the type of exposed data module and on the connection protocol.
Lifetime of a Server Module
A Server application created using DataSnap technology contains an instance of TDSServerClass. The LifeCycle property for this instance specifies the lifetime of the server module. The possible values are:
- Invocation
- Server
- Session (set by default)
Invocation
The Invocation life-time setting tells DataSnap server to create a new instance of the specified data module for every client request. If the data module exposes server methods, then for each method call a new instance is created. After the call, data modules are automatically destroyed.
Server
If the Server life-time setting is chosen, DataSnap server creates and then reuses the instances of data modules for each connected client. Server is useful when the data module is designed to be "client-agnostic" and it can serve any client that uses it. All data modules created using this setting are freed when the DataSnap server is shut down.
Session
The Session option is set by default and is designed to be the best alternative in most circumstances. When in Session mode, the DataSnap server creates one data module instance per client. The data module exists as long as the client is connected. When the client disconnects, the instance is freed. This allows you to maintain distinct information that can be used at any time during the session.
Pooling Data Modules (COM)
If you are creating a transactional data module that will be installed to COM+, you can use the COM+ Component Manager to install the application server as a pooled object.
Even if you are not using a transactional data module, you can take advantage of object pooling if the connection is formed using TWebConnection. Under this second type of object pooling, you limit the number of instances of your data module that are created. This limits the number of database connections that you must hold, as well as any other resources used by the data module.
When the Web Server application (which passes calls to your remote data module) receives client requests, it passes them on to the first available remote data module in the pool. If there is no available remote data module, it creates a new one (up to a maximum number that you specify). This provides a middle ground between routing all clients through a single remote data module instance (which can act as a bottleneck), and creating a separate instance for every client connection (which can consume many resources).
If a remote data module instance in the pool does not receive any client requests for a while, it is automatically freed. This prevents the pool from monopolizing resources unless they are used.
To set up object pooling when using a Web connection (HTTP), your remote data module must override the UpdateRegistry method. In the overridden method, call RegisterPooled when the remote data module registers, and UnregisterPooled when the remote data module unregisters.
When using either method of object pooling, your remote data module must be stateless. This is because a single instance potentially handles requests from several clients. If it relied on persistent state information, clients could interfere with each other. See Supporting State Information in Exposed Data Modules for more information on how to ensure that your remote data module is stateless.