This is right. I specially mention earlier in the article I use “REPEATABLE READ” in Innodb sense not in ANSI Sense. This Will look like double bug to most MySQL/Innodb users.

Most applications written for MySQL/Innodb rely (often unintentially) on this behavior.

On the side note I personally think in this case standard is flawed, probably done to accommodate vendors who could not implement repeatable read to be simply repeatable read without any exceptions. It is easy to explain easy to use.

Just to note – even some MySQL tools rely on it. Ie mysqldump –single-transaction is used to dump transactional tables in consistent snapshot using repeatable-read isolation. This obviously would not work with phantoms.

PESSIMISTIC mode, Test 3 Phantom rows:
…
In this case we get phantom row, which looks like double bug to us.
First we should not get phantom row in repeatable-read isolation mode,

Actually ANSI/ISO Standard for SQL allows phantom rows phenomena at REPEATABLE READ isolation level.
It is not allowed only at the highest isolation level, which is SERIALIZABLE.

Was it a mistake in your text ? If so, I think it is better to correct the text.

Other notions are more or less consistent.

Thank you for response.

One additional from me – In the latest bug with Sysbench I used optimistic (default) locking.

Thanks for taking the solidDB for MySQL Beta 3 for a test run. We have come a long way, and of course there is still a ways to go. We know that we have additional work to do on quality and functionality of our integration with the MySQL Server. I will address below the rest of the issues that you raised.

About the pessimistic locking, our release notes mention that we do not yet support pessimistic locking. However, we could have been clearer. We will improve the documentation before next release.

Regarding Test 2 for optimistic locking, thanks for catching the bug. It’s unfortunate that this bug slipped through our QA process. We have already fixed this in our latest code base, and the fix will show up in next release.

The suggestion to have “SHOW SOLIDDB STATUS” is a great suggestion. I will investigate our support for showing status information or try to get this functionality added in a future release.

I believe that you meant to place Test 5, which you have listed under the pessimistic cases, with the other optimistic locking cases. You are correct in noting that our error message is wrong. This will be fixed in the next release.

You are also correct in noting that our SELECT FOR UPDATE behaves differently from InnoDB. One thing to remember is that our Storage Engine for MySQL comes from our main code base, which has been commercially available since 1994 or so. That is the behavior of our core product (BoostEngine). However, you bring up an important point. Migration from other storage engines, and compatibility with them, is an important area that we are currently working on. This is an area where we especially value community feedback.

The problem with SysBench may be related to the fact that we do not yet support pessimistic locking. We will investigate this further to see if that is the case. We will of course support SysBench and other benchmarks.

As we ramp up our processes, we expect to encounter some hiccups, but we are dedicated to producing a quality product, with the participation of our community. We appreciate your feedback, and thanks again for all your help.

Jonathan Cheyer
Open Source Community Manager
Solid Information Technology