Hehe, I had similar thoughts when developing the transaction bits to the
transaction log. I like your thoughts. Comments inline. :)
Paul McCullagh wrote:
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.
Yes, and another problem I've run into is that there doesn't seem to be
any way of getting a unique transaction ID (at the very least specific
to the Drizzled instance) for such transactions.
Yet another issue is the problem of a "normal transaction" vs. a
"statement transaction" and the corresponding confusion of the
"bool all" arguments...
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)
From a StorageEngine perspective, what we currently have is this:
virtual int commit(Session *, bool);
virtual int rollback(Session *, bool);
int savepoint_set(Session *session, void *sp);
int savepoint_rollback(Session *session, void *sp);
int savepoint_release(Session *session, void *sp);
virtual int prepare(Session *, bool);
virtual int recover(XID *, uint32_t);
virtual int commit_by_xid(XID *);
virtual int rollback_by_xid(XID *);
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)
:) This is, actually, exactly how the ReplicationServices component
works (in fact the method names are virtually identical.)
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.
Yep, makes sense. Basically, what you are doing is removing the legacy
confusion around a "normal transaction" and a "statement transaction",
and the need for the ha_register_trans() stuff, passing false for a
statement transaction.
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!
yep.
The rule is simple:
1. In auto-commit mode: start a transaction when a statement is
executed, and end it after the statement.
++, though changing the existing code is a bit trickier than you might
think :)
2. Otherwise, start a transaction when a statement is executed and end
on an explicit COMMIT or ROLLBACK.
Or on an implicit COMMIT...
This is, actually, what happens now. It is just not very clear because
of the whole passing a bool all thing (to indicate if the commit is a
"real" transaction or not...
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
From the Cursor, you mean....and put onto the StorageEngine. yes. ++
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
Correct! The only reason I can see in the code why it does so now is
for legacy reasons of indicating to BerkeleyDB what type of transaction
to commit internally...
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
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
