ASTA Multi-Threading
In order to scale successfully and handle a large number of concurrent users, AstaServers offer three different threading models. Our advanced threading techniques occur under-the-hood so that developers can leverage the benefits of multi-threading without having to deal with the complexities.
Our threading models are just one piece of a multi-part solution to scaling your application; it is critically important that you design your application well, particularly your database. It is also important that you supply ample bandwidth. If you supply the bandwidth and a well tuned database, ASTA will delivers the rest.
In a heavy usage situation, many client requests may arrive at the AstaServer simultaneously. The AstaServerSocket is non-blocking and event driven so that client requests are always handled. The question isn't whether or not the client query will receive a response, the question is one of timeliness; will the response time be acceptable to the user? That's where threading comes into the picture.
In a single-threaded model, the AstaServer responds very quickly, but
all the clients must "pipeline" one behind the other. If you
are the fifth client to make a request, you must wait for clients one
through four to be served first [This process is surprising quick and
not as bad as it sounds. In fact, unless your queries are really complex,
this model will deliver the best performance for most applications]. But
what happens when you are tenth in line, and the second client in line
has made a time-consuming request? That is when multi-threading delivers.
When the AstaServer is run in a multi-threaded mode, many queries can
execute simultaneously.
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).
When run in the PooledSession threading model, AstaServers, in order to
allow for greater scalability, create and maintain a pool of Sessions
that are available on an as-needed basis for connected clients. A TAstaSessionList
is created and acts as a Resource Dispenser that supplies client sessions
upon request. Instead of creating a session for each connected client,
AstaServers pool the sessions and dispense them when they are needed.
In order to achieve maximum scalability, resources should be acquired
as late as possible and released as soon as possible. State should only
be maintained when only absolutely necessary.
AstaServers can also maintain client Database State while the client is
connected to the server. This resource-intensive 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.
You can use one of three different threading models in you AstaServer. The selection is made via the AstaServerSocket's ThreadingModel property.
- tmSingleSession
- This is the default model and should be the fastest for small numbers of users or larger numbers of users that don't have excessive concurrent activity.
- tmPooledSessions
- This is a resource conscious scaling model. Use the DataBaseSessions:Integer property to set the number of sessions that are created at server startup. All connections are created at server startup and client requests are paired with sessions from this pool on an as-needed basis. If you are trying to support a large number of users, this is the model to use.
- tmPersistentSessions
- This model allows each client to connect to a Session when the client
connects to the server. The sessions are persistent. Used in conjunction
with the TAstaClientSocket Login property, you can use this threaded
model to allow users to login with their actual database login, and
even allow each client to access a separate Alias. When the client connects,
the socket triggers an event (DBLoginEvent) to create a Database session.
Any subsequent client database access will pair the incoming socket
with the session chosen at startup, within a spawned thread. When the
client disconnects, the session is disposed of.
When an AstaServer runs in this mode, AstaClients can fire a server query and keep a cursor open on the server. Instead of fetching all the records in the query the client can request X number of rows via the PacketSize:Integer property. See the Packet discussion in the TAstaClientDataSet.Doc.
There are three steps to enabling a Multi-Threaded AstaSever.
- Set the ThreadingModel Property. If the tmPooledSessions is chosen,
then you must set the DataBaseSessions property as well.
- Code the ThreadedDBSupplySession Event.
- Code the ThreadedDBSupplyQuery Event
When an AstaServer starts up, the method CreateSessionsForDbThreads is called. If the DataBaseSessions property is greater than 0, and the ThreadedDBSupplySession Event and the ThreadedDBSupplyQuery event is coded, than an AstaSessionList can be created that will act as a pool of connections to the database. If you choose to thread the server, these two events must be coded! Use the Function UseThreads: TAstaThreadModel to verify at runtime which threading model is in effect.
This document is continued in the AstaThreadedDB.doc distributed with an evaluation version of the components.
