Transaction Isolation Level Serializable in NDB

[Philip McGee]

I am currently evaluating MySQL Cluster for use in an application that would benefit from the availability of the Serializable Transaction Isolation Level. The MySQL Reference Manual, section 16.8. Cluster Limitations in MySQL 4.1, states:

"The only supported isolation level is READ_COMMITTED."

I understand the performance limitations of serializable transactions, but our application does not require high throughput. We are considering the cluster for it's high availability, automated fail-over and synchronous data replication, not for its scalability. I believe I can work around specific concurreny issues by using appropriate Update ... Where ... constructs, but our application uses Hibernate for data persistance, and intermingling Hiberanate's automated schema and query generation with specific hand coded queries is unappealing because of the maintenance required to support the ongoing development and evolution of the application.


1. Are there plans to support transactions with serializable isolation levels in future versions of MySQL Cluster? If so, for what version?

2. What information is available on concurrency control techniques in NDB? The MySQL Reference Manual does not mention NDB in the sections dealing with Locking Issues or Transactional Statements, and the section on MySQL Custer offers no specifics on concurrency other than the limitation statement given above.

3. Might I be better off using InnoDB and trying to implement synchronous replication with a two-phase commit? It seems that would provide data security, but not high availability.


Thank you.