← Back to team overview

drizzle-discuss team mailing list archive

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


Hi Brian,

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 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).

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 tables involved.

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).

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.

Best regards,


Paul McCullagh
PrimeBase Technologies

Follow ups