← Back to team overview

drizzle-discuss team mailing list archive

Re: Improving the Engine API (was Re: New PBXT Drizzle-specific storage engine...)


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:
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