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 7:44 PM, Brian Aker wrote:
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
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
Yup, it definitely make sense to leave this to the engine.
If we have a startStatement() call, then it could be used in place of
beginAlter(), assuming we can determine the statement type, and the
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
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).
Internally this the way PBXT locks a table. We basically do a "close
table pool". When a thread wants to lock the table, it sets a flag
which indicates that the pool of table handles is to be closed.
Then, when a handle is returned to the pool it is deleted, instead of
adding it back to the pool.
The locking thread waits until all handles are returned and deleted
before it can proceed. The lock on the pool then prevents a new table
handle from being created while the locking thread is busy.
Either way, it would be good if Drizzle closes all handlers/cursors
before a table is deleted or renamed.
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.
I guess I am. PBXT actually supports this.
2) We don't have LOCK TABLE :)
OK, this make things a lot simpler! Indeed, if we don't need to
support LOCK TABLE then external_lock() can be removed altogether.