OK, great. I would be interested to try out the changes.
So we can get it into the new storage_engine.cc you created for PBXT,
and see how it runs.
On Dec 3, 2009, at 6:03 PM, Jay Pipes wrote:
We're in full agreement.
Since this actually lends itself to my current docket of work, I
will work on implementing these suggestions this week and will post
back to this mail with a link to the code review of the relevant
merge for you to add your input.
Cheers!
Jay
Paul McCullagh wrote:
Hi Jay,
On Dec 3, 2009, at 5:24 PM, Jay Pipes wrote:
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...
Yup, drives me crazy!
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.)
I just makes sense, doesn't it ... :)
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.
Exactly. And replaces that with simple concepts that everyone
understands.
And if the engine is non-transactional, then you don't even have to
know the call exist (just like those that do not support XA).
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 :)
Hmmm, I suspected that! I have scratched around in that code
myself :(
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...
Yes, the end statement/transaction calls are in the code. So it
would be easy to change those calls.
The begin statement/transaction calls are not, so that would take
some effort as you say.
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. ++
Yes, it belongs on StorageEngine, but I am basically proposing
replacing this with startStatement and endStatement.
The way it is currently called, a start_stmt() call translates to:
endStatement(); startStatement();
Best regards,
Paul
--
Paul McCullagh
PrimeBase Technologies
www.primebase.org
www.blobstreaming.org
pbxt.blogspot.com
--
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
