SELECT .. LOCK IN SHARED MODE requires that read locks are held after completing the query. This can only be accomplished by implementing takeOverForRead in NDB API and using this in the handler. There is also a dependency to a task where rows that are not used will call unlock_row so that takeOverForRead is only called when needed. This means that scan with LM_Read needs to be able to request KEYINFO. In order not to lock unnecessary rows this work also includes implementing support for handler::unlock_row Also, to generalize, an implementation could be done where the current isolation level decides if locking should be done to support TRANSACTION_REPEATABLE_READ. Since this would be a performance degradation the current default isolation level should probably lowered to TRANSACTION_READ_COMMITTED (as in Oracle) and to issue a warning if one sets TRANSACTION_REPEATABLE_READ that this impacts performance.