Filter
Top Products
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, each node being responsible for a
subset of the data, or 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,
see the Reliable Transaction Router Application Design Guide.
Object-Oriented Programming
The C++ foundation classes map traditional RTR functional
programming concepts into an object-oriented programming
model. Using the power and features of these foundation
classes requires a basic understanding of the differences
between functional and object-oriented programming concepts.
Table 2–1 compares the worlds of functional programming and
object-oriented programming.
Architectural Concepts 2–5