[Bernstein09] Section 3.5. Transaction Servers

3.5. Transaction Servers
is the application program that does the real work of running therequest. Part of that work usually involves reading and writing shareddatabases. It always executes in the context of a transaction, oftencreated by the request controller that called it.
Itcan be a self-contained program or it might call other programs to doits work. Those other programs might execute on the same system as thetransaction server that calls it or on a remote system that requires acommunications message to go from the caller to the callee. Thecommunications must be transactional, so that the transaction contextflows along with the messages. This typically is done usingtransactional RPC, as discussed inSection 2.4.
Forapplication portability, it’s desirable that the transaction servers bewritten using a popular programming language such as COBOL, C++, C#,FORTRAN, or Java. It is also desirable that they express databaseaccesses in a widely used data manipulation language, such as SQL. Thisensures that the transaction server part of the application can beported to different transactional middleware environments.
Fromthe viewpoint of the application programmer, transaction servers areordinary data access programs. The application programmer needs toensure the program preserves database integrity, doesn’t take too longto execute and thereby create a resource bottleneck, uses timeouts todetect database server failures, returns comprehensible error messages,copes with distributed databases, and so on. These are complex issuesthat arise forany data access program. There is little that the programmer needs todo differently to run the program in a transaction server process.
Process and Session Structure
Fromthe viewpoint of process structure, transaction servers have severalspecial considerations, which are related to their need to scale tohigh request rates and to support transaction-based communications.
For scale-out, a transaction server Sneeds to have enough threads to handle the system’s maximum requiredload. Although figuring out the right number of threads is really anexperimental science, the following back-of-the-envelope calculationshows which factors are at stake. Suppose each transaction requires tseconds of elapsed time to be processed by the transaction server. Ifthe transaction server has one thread, then it can process 1/t transactions per second. Thus, if the system needs to handle a peak load of n transactions per second of the transaction types implemented by S, then t × nthreads are required. Actually, somewhat more are required, due tovariance in elapsed processing time. The latter is dependent in largepart on the time it takes to process its database operations, which isusually where most of the time is spent. This varies based on databaseserver load, which may include database operations from othertransaction servers.
Toaccess a database system, every active transaction in a transactionserver process needs a database session with the database system. Thus,the number of database sessions required is comparable to the number ofthreads in the transaction server. Since it is relatively expensive tocreate a database session, it is desirable that they be pooled andreused.
The useof database sessions has security implications, because part of thedatabase session is the ID of a database user, which usually cannot bechanged after the session is created. The database system uses that IDto do an authorization check of each operation executed on thatsession. Usually, the user ID of the database session is that of adedicated account with sufficient privileges to access the data neededby the transaction server. This allows sessions to be reused fordifferent requests and hence pooled. By contrast, if the user ID werethat of the end user who is issuing the request, then a new sessionwould have to be created on that user’s behalf, unless the user happensto have executed another request in the very recent past and thereforealready has a database session set up. Also, if the user ID were thatof an end user, then a database administrator would have to create adatabase user account for every end user who can access the database.This is not feasible for TP applications that are accessed by a largenumber of end users only occasionally, a few times a year, such as aretail e-commerce site.
Thededicated account usually is given read-write authorization on allparts of the database that may be accessed by the given transactionserver. That is, the database system treats the transaction server as atrusted user. Thus, it is up to the transaction server to check that agiven end-user request is authorized to perform the database operationsrequired.