Thoughts about working in a distributed organization – Lenz Grimmer's blog Lenz Grimmer hat seinen Vortrag zum MySQL HR Motto ("The freedom to work anywhere you want") aktualisiert und ein paar Gedanken zum…

This is a fantastic improvement which will make implementing an engine much simpler in the future!

My problem with start statement/end statement was that I had found a case when the counting method did not work. And Kristian showed that in this case InnoDB also produces the incorrect result. If anyone wants more details they should search the Internals List archive for “Finding the start of a statement”.

If you check the PBXT handler implementation (ha_pbxt.cc) you will count 14 GOTCHA comments. And those were just the ones that particularly burnt me. So having wrestled with the engine API for so many years, this last frustration was just too much!

Put simply: changes you have made are badly needed. They are also good because they are the result of much discussion and thinking. For example, stored procedures lead to nested statements, which can be easily handled by the new API.

Just the fact that the changes makes it possible for non-engine plugins to do XA proves that this is a huge step forward. And now things are really falling into place, because this is about to solve the transactional problems that MySQL replication has had all along.

Paul's problem did actually exist in Drizzle because there was no notification guarantee until this recent work was committed that an engine would be notifiied of a new SQL statement starting or an old one finishing. What Monty wrote was precisely what InnoDB had to do (count locks on cursors in order to know when to call trans_register_ha() and commit() (just look in the InnoDB handler if you don't believe me ). With this new work, none of that is necessary. InnoDB doesn't need to call trans_register_ha(), doesn't count cursor locks in Cursor::external_lock() because there is an explicit call to StorageEngine::doEndStatement() when a SQL statement ends.

I don't know what we would do if we supported stored procedures, but I'm pretty sure it would follow the same principles: explicitly tell the engine when a SQL statement (whether inside a procedure or not) starts. A stored procedure is really nothing but a stored set of SQL statements, and should be coded up as such. It's not a separate SQL statement in and of itself, at least according to the storage engine, it's not.)

Cheers!
-jay

Hi Kostja!

That’s good to hear that the statement boundaries are more explicit in MySQL 5.5. For storage engine developers, it’s a clear win.

-jay

… since in the server all tables are pre-locked and cursors are pre-opened before start of any substatement.

But we *do* actually call start_statement() on each handler for each substatement
of a stored function or trigger.