Threading ASTA Servers

In order to handle a large amount of concurrent users, ASTA servers can multi-thread their database sessions. The AstaServerSocket is non-blocking and event driven so that client requests can always be handled. Performance issues are normally related to bandwidth considerations and a properly designed client application is critical if you want your ASTA server to respond promptly to requests.

In order to multi-thread any database application, each user must have their own connection or session to the database, and their own copy of the component that is to be used in conjunction with this session, usually a query or stored procedure component. Using the BDE, each client needs a TSession and their own TQueries. Using ODBC, each client would need their own handle to a database (THdbc) and their own query component (TOEDataSet using ODBCExpress).

ASTA servers can run in one of 3 different threading models: Singled Threaded, Persistent Sessions and Pooled. There are command line switches that can be used to configure ASTA servers at run time.

For small numbers of users the Single Threaded model is the most efficient mode to run an ASTA Server. The most scalable is the Pooled Threading Model. If you want to be able to keep an open cursor on an ASTA server and be able to use packetized queries on ASTA clients, or use database user name and password, use the Persistent Threading Model.

ASTA servers can also maintain client database state while the client is connected to the server. This model will not scale as well, but there may be certain occasions where you would want a client to keep a persistent database connection. For example, you might want a client to use a real database name and password to keep their database security level applicable to them or when you want to open a server side cursor and fetch partial rows from the server.

See Coding ASTA Servers for steps to create an ASTA server.