Availability Guide for Application Design

Designing Applications for Change
Availability Guide for Application Design—525637-004
10-9
Considering Portability Requirements
Increasingly, OLTP applications require 24 x 7 availability, with the elimination of
traditional batch windows. This requires that batch update programs implement
efficient logical units of work and locking strategies to coordinate with concurrent
OLTP operations on the same database.
OLTP
The dominant enterprise processing model is OLTP, which is performed from
terminals, workstations, or automated devices such as automated teller machines.
The initial move was toward the two-tier client/server model, but now the three-tier
or distributed function client/server model is emerging as the preferred solution.
This model locates the bulk of the business logic in the central application server
hosts rather than in the client, and invokes that logic through some form of remote
procedure call (RPC) interface.
The use of Internet browsers with Java applets for the application’s user interface
functions might reinforce this server-centric processing model or might favor
passing the business logic to the client for execution there. The combination of
Java technology with distributed object technology favors the former.
Architectural Models for Server-side OLTP
There have been two dominant models for implementing server-side OLTP functions:
•
Instance-per-user
•
Multithreaded instance
A third model, process pools, was pioneered by HP for its clustered NonStop servers.
Instance-Per-User Implementations
Instance-per-user implementations create a set of the necessary processes for
each user session. This model can support multiprocessor execution and therefore
has the potential to scale. However, for very large user populations, problems may
arise in shared resource access and in system limits. The large number of
processes can also lead to manageability problems, and the cost of repeated
process creation and associated file opening can become a significant
performance issue. This is more frequently acknowledged today—even by UNIX
system developers who previously were strong believers in this mode.
Multithreaded Instance Implementations
Multithreaded instance implementations are relatively difficult for business
application developers to create, but are common in mainframe middleware such
as IBM’s CICS API. Such implementations reduce process creation, can share
resources such as file or database opens between threads, and are inherently
more compact to manage than instance-per-user systems. The concurrent
execution of multithreaded applications can be limited to a single processor if user-
provided threads are used, or may exploit an SMP system if operating system
threads are used. In the latter case, scalability may still be limited by contention for
shared-memory structures or other limits on total system resources.