Hi!
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 :)
Cheers,
-Brian
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
