On Dec 22, 2009, at 11:10 PM, Jay Pipes wrote:
Yes, OK. I think this makes it even more obvious that t2 is being
read, and t1 is being read and updated.
Here is some pseudo code for the execution of this statement:
engine->beginTransaction()
engine->startStatement(gpb_stat_info)
a = engine->getCursor("t1", WILL_UPDATE)
b = engine->getCursor("t2", READ_ONLY)
Actually, the above is not correct. Because the update to t1 is
dependent on rows in a consistent snapshot of t2, you would
actually have to do (again, in pseudocode):
b= engine->getCursor("t2", REPEATABLE_READ);
a= engine->getCursor("t1", WILL_UPDATE);
Yes, generally I agree.
In fact, WILL_UPDATE may be: COMMITTED_READ | FOR_UPDATE (at least
I believe this is the case with InnoDB).
Unless the engine uses "optimistic locking" (which is the pure MVCC
approach), and then it would be: REPEATABLE_READ | FOR_UPDATE.
So this raises the question of whether the use of REPEATABLE_READ
and COMMITTED_READ is not telling the engine too much about how
these things should be implemented...?
No, I don't view it as implementation, really. The REPEATABLE_READ
or COMMITTED_READ is something the kernel has to communicate to the
engine because it is what the *user* has asked for -- either
explicitly or via a configuration default. So, it's not really the
kernel saying to the engine "do it this way". Instead, it's the
kernel saying "this is what the user is requiring." So, in that
sense, I believe it absolutely belongs in the API.
Yup, OK.
I want to flesh out the example code we've been working on in this
thread some more. I will do this over the holidays and post the
code to the wiki I've been using. I'll take the approach of
demonstrating how the kernel would call the engine for various SQL
scenarios. Hopefully, that will give us a rounded look at the way
the kernel can interact with the engine and the engine's cursors.
Yes, I think that is approach makes it easy to understand.
--
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