Hi All,
Recently I discovered that a hack I put in to solve a problem in a
early version of MySQL 5.1, prevented PBXT XA from working with the
binlog.
Part of the confusion comes from the fact that it is really not
obvious to the engine where a statement/transaction begins and ends.
I know we already have plans to improve this (and perhaps even code).
Anyway, I would like to throw in some suggestions for discussion...
Currently we have:
StorageEngine::commit(session, bool all)
StorageEngine::rollback(session, bool all)
I suggest we change this to the following:
StorageEngine::beginTransaction(session)
StorageEngine::commitTransaction(session)
StorageEngine::rollbackTransaction(session)
StorageEngine::startStatement(session)
StorageEngine::endStatement(session, abort = true/false)
So here is an example of the call sequence to the engine in the case
of a simple SELECT statement (assuming we are in auto-commit mode):
StorageEngine::beginTransaction()
StorageEngine::startStatement()
handler->external_lock() // open-cursor t1
...
handler->external_lock(F_UNLCK) // close-cursor t1
StorageEngine::endStatement(false)
StorageEngine::commitTransaction()
So the idea is that startStatement and endStatement "bracket" a
statement, and that beginTransaction and commitTransaction/
rollbackTransaction indicate the transaction boundaries, whether in
auto-commit mode or not.
This setup has quite a few advantages:
* The engine no longer needs to call trans_register_ha()
trans_register_ha() is used by the engine to tell MySQL when a
statement level or session level transaction is started. However, this
is not necessary because the time to start a transaction is not
variable!
The rule is simple:
1. In auto-commit mode: start a transaction when a statement is
executed, and end it after the statement.
2. Otherwise, start a transaction when a statement is executed and end
on an explicit COMMIT or ROLLBACK.
With the current API it is left to the engine developer to figure out
which handler calls and which flags correspond to the beginning of a
transaction.
* start_stmt() can be removed
It does not belong on the handler anyway as the start of a statement
has nothing to do with a cursor.
* The engine need not track auto-commit mode
Instead, the Drizzle server knows about auto-commit mode, and calls
commitTransaction or rollbackTransaction at the right moment.
Best regards,
Paul
On Nov 19, 2009, at 9:17 PM, Jay Pipes wrote:
Hi Paul!
I've pushed a new branch up to Launchpad:
lp:~jaypipes/drizzle/pbxt-working
This branch removes the MySQL-specific plugin, handler, handlerton
stuff in favor of the Drizzle StorageEngine and Cursors. All
#ifdefs have been removed which makes reading the source files a
heck of a lot easier :)
I'll continue working on the branch. I've noticed (as have you I'm
sure) that most of the test failures are because EXPLAIN is
returning slightly different results (because the default result
files are specific to InnoDB or MyISAM) or that some InnoDB-specific
warnings don't appear in the results file. I'll work with Vlad to
clear these up.
Cheers!
Jay
--
Paul McCullagh
PrimeBase Technologies
www.primebase.org
www.blobstreaming.org
pbxt.blogspot.com
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
