Note Check the solidDB Release Notes for any limitations that are associated with using a grid in the current release.
The following scenarios demonstrate the results of specific configurations that might not be successful. In each case, a client application attempts to perform a number of operations to a grid that contains three nodes.
Notes
▪ All the scenarios assume that the transactions run in the default write mode for a grid.
▪ For ease of explanation, the target nodes for the operations that are defined in the client application are indicated in the diagram. However, the client application does not know the target nodes; they are resolved by the grid-aware driver.
Single transaction updates rows on more than one node
In this scenario, the client application runs a single transaction. The single transaction involves writing to two or more rows that are on different nodes.
The grid-aware driver identifies the node that contains the primary replication unit for the partition for the first row that is affected, and routes the statement to that node (N1). The write operation to the first row completes successfully. However, because the transaction is still open, the rest of the statements are routed to the same node.
The only other write operations that complete successfully are those where the primary replication unit for the partition of the affected rows is also hosted on node N1.
Note All read statements would run successfully on node N1 regardless of where the primary replication unit for the partition of the affected rows is located.
Transaction includes a stored procedure
In this scenario, the client application runs a stored procedure. The stored procedure transaction involves writing to two or more rows that are on different nodes.
The grid-aware driver cannot interpret the content of a stored procedure to make any decisions about which node should execute the procedure. Thus, regardless of the content, the stored procedure is executed on the node where the previous statement was executed or, if there was no previous statement, the node that was specified in the driver connection string (in this scenario, N3).
The only write operations that complete successfully are those where the primary replication unit for the partition of the affected rows is hosted on node N3.
Note All read statements would run successfully on node N3 regardless of where the primary replication unit for the partition of the affected rows is located.
Client application makes direct database connection to grid node
In this scenario, the client application uses a direct database connection to a grid node (N2) instead of a grid-aware driver. All transactions are routed to node N2 but the only write statements that complete successfully are those where the primary partitions of the affected rows are hosted on node N2.
Note All read statements would run successfully on node N2 regardless of where the primary replication unit for the partition of the affected rows is located.
