Note Check the solidDB Release Notes for any limitations that are associated with using a grid in the current release.
One of the most important factors in achieving application transparency for the grid is routing the queries and updates to the correct grid node. Without any assistance from the grid, it is difficult for the application programmer to know which nodes are hosting which tables and rows.
To alleviate this problem, the solidDB ODBC and JDBC drivers are grid-aware and can route statements to the correct node for execution.
In order to obtain all the required information to correctly route statements, the driver performs the following tasks:
▪ When the grid-aware driver connects to any node in the grid, the driver pulls the grid configuration metadata from the node. The metadata contains the following information:
▪ network addresses of all grid nodes,
▪ location of the primary replica of all non-partitioned (shared) tables,
▪ location of the primary replication unit for the partition of each row of a partitioned table.
▪ When the grid topology or table partitioning changes, the driver performs the following tasks:
▪ pulls the new metadata during the next interaction with any grid node,
▪ attempts to redirect any connections to nodes based on any changes in the grid configuration,
▪ attempts to redirect any statements to the correct nodes based on any changes in the table partitioning information.
Executing a statement
Preparing and executing statements on a grid node is performed in the same way as with a standalone database. However, when you execute a statement in a grid node, there are some grid-specific error messages and performance-related considerations that must be taken into account by the application programmer, see Grid application considerations.
When an application executes the first (or only) statement in a transaction, the following steps are performed:
1 The application opens a new ODBC (or JDBC) connection to a grid node by using the grid-aware driver. The connection is made to the same grid node that was used for the previous operation or, if there was no previous operation, the grid node that is specified in the driver connection string.
2 The application receives a logical ODBC (or JDBC) handle for the corresponding object. Internally, these application-level logical handles might contain multiple physical connection (or statement) handles into several (or even all) grid nodes.
3 The driver prepares the statement on the currently connected node.
After the statement has been prepared, the next steps vary depending on whether the statement is a read operation (SELECT statement) or a write operation (INSERT, UPDATE, or DELETE statement).
4 During the execution phase of the statement, the target grid node for the statement is calculated by using the grid configuration metadata.
If the target node for the statement, is not the node where the statement was initially prepared, the driver re-prepares and executes the statement on the correct node.
Important In order to route the statement execution appropriately, the statement must use parameter markers for the partitioning key column. If the statement is executed with literal values, the statement succeeds only if the current node hosts the primary replication unit for the partition of the partitioning key value; otherwise, the following error is returned: SOLID Table Error 13630: Writes are allowed only in Grid primary partition
