• Transaction isolation level. The NDBCLUSTER  storage engine supports only the READ COMMITTED  transaction isolation level. ( InnoDB , for example, supports READ COMMITTED , READ UNCOMMITTED , REPEATABLE READ , and SERIALIZABLE .) You should keep in mind that NDB implements READ COMMITTED  on a per-row basis; when a read request arrives at the data node storing the row, what is returned is the last committed version of the row at that time. 

Uncommitted data is never returned, but when a transaction modifying a number of rows commits concurrently with a transaction reading the same rows, the transaction performing the read can observe “before”  values, “after”  values, or both, for different rows among these, due to the fact that a given row read request can be processed either before or after the commit of the other transaction. 

To ensure that a given transaction reads only before or after values, you can impose row locks using SELECT ... LOCK IN SHARE MODE . In such cases, the lock is held until the owning transaction is committed. Using row locks can also cause the following issues: 

•Increased frequency of lock wait timeout errors, and reduced concurrency 

•Increased transaction processing overhead due to reads requiring a commit phase 

•Possibility of exhausting the available number of concurrent locks, which is limited by MaxNoOfConcurrentOperations 

NDB  uses READ COMMITTED  for all reads unless a modifier such as LOCK IN SHARE MODE  or FOR UPDATE  is used. LOCK IN SHARE MODE  causes shared row locks to be used; FOR UPDATE  causes exclusive row locks to be used. Unique key reads have their locks upgraded automatically by NDB  to ensure a self-consistent read; BLOB  reads also employ extra locking for consistency. 

See Section 23.5.8.4, “NDB Cluster Backup Troubleshooting” , for information on how NDB Cluster’s implementation of transaction isolation level can affect backup and restoration of NDB  databases. 

• Transactions and BLOB or TEXT columns. NDBCLUSTER  stores only part of a column value that uses any of MySQL’s BLOB  or TEXT  data types in the table visible to MySQL; the remainder of the BLOB or TEXT  is stored in a separate internal table that is not accessible to MySQL. This gives rise to two related issues of which you should be aware whenever executing SELECT  statements on tables that contain columns of these types: 

1. For any SELECT  from an NDB Cluster table: If the SELECT  includes a BLOB  or TEXT  column, the READ COMMITTED  transaction isolation level is converted to a read with read lock. This is done to guarantee consistency. 

2. For any SELECT  which uses a unique key lookup to retrieve any columns that use any of the BLOB  or TEXT  data types and that is executed within a transaction, a shared read lock is held on the table for the duration of the transaction—that is, until the transaction is either committed or aborted. 

This issue does not occur for queries that use index or table scans, even against NDB  tables having BLOB  or TEXT  columns. 

For example, consider the table t  defined by the following CREATE TABLE  statement: 

CREATE TABLE t ( a INT NOT NULL AUTO_INCREMENT PRIMARY KEY, b INT NOT NULL, c INT NOT NULL, d TEXT, INDEX i(b), UNIQUE KEY u(c) 

