drizzle-discuss team mailing list archive
Mailing list archive
Re: Improving the Engine API (was Re: New PBXT Drizzle-specific storage engine...)
On Dec 3, 2009, at 10:33 AM, Paul McCullagh wrote:
> I use it to convert a lock of type (for example) TL_WRITE to TL_WRITE_ALLOW_WRITE, just like InnoDB, to allow concurrent updates.
> But otherwise, I don't specifically require the call, especially if table locking is to be handled differently.
Name locks work as always, but my current thinking is that we will call:
1) StorageEngine::beginAlter(TableIdentifier &) At this point you can gain a write lock on the table if you need one during the alter table (for instance... archive can just continue to log and replay on the new table on open... so need to gain a write lock under some conditions).
2) We just simplify it down to how flush table works on the table... close everyone out, grab the lock from the share and let everyone read.
Two would be simpler to do at the moment, but I am still a couple of steps away. A rename will still be called for the moment (aka... I'm not touching that until some other work is done).
I just went over this with Jay on the phone, if you want to talk about this on Skype I can go into more details.
> Basically I see the following, external_lock() is used to do a number of things:
> 1. Acquire a handler for exclusive use by a thread (and then use it as a cursor).
> 2. Lock a table (implicitly, or via an explicit LOCK TABLE call).
> 3. Signal the start of a transaction or statement.
> If we add the functions discussed previously then (3) above need no longer be done in external_lock().
> What are you planning to do about (1) and (2)?
1) I'm not following you on this one. Are you talking about the historic means for doing shared table access by MyISAM? If so, I think that is mute. I believe Maria even dropped support of this.
2) We don't have LOCK TABLE :)