HP Reliable Transaction Router - Manual (Page 44)

The Partitioned Data Model
The Partitioned Data Model
One goal in designing for high transaction throughput is
reducing the time that users must wait for shared resources.
While many elements of a transaction processing system can be
duplicated, one resource that must be shared is the database.
Users compete for a shared database in three ways:
• For use of the disk
• For locks on database records
• For the CPU resources needed to access the database
This competition can be alleviated by spreading the database
across several backend nodes, where each node is responsible
for a subset of the data contained in a partition. RTR enables
you to implement this partitioned data model, shown roughly in
Figure 2–2 where the database has three partitions. RTR routes
messages to the correct partition on the basis of an application-
defined key. For a more complete description of partitioning as
provided with RTR, refer to the HP Reliable Transaction Router
Application Design Guide.
Each RTR API provides the capability to use partitions. For
specific information on declaring and using partitions, see the
RTR documentation for the system manager and the applications
programmer.
Object-Oriented Programming
Java objects and the RTR C++ foundation classes map traditional
RTR functional programming routines into object-oriented
programming models. Using the power and features of the
Java objects or the foundation classes requires understanding
of the differences between functional and object-oriented
programming concepts. Table 2–1 compares the worlds of
functional programming and object-oriented programming.
2–6 Architectural Concepts