Hi!
On Dec 4, 2009, at 3:12 AM, Paul McCullagh wrote:
> 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.
The problem with relying on statement type is that at some point statement type
will be pluggable... which means you would constantly need to update your
engine for new statements.
Yuck!
I was talking to Toru about this, and another possibility is that we have
statements declare a needed "lock type" that any plugin could then query. I
outlined the solution for Toru, but I don't know if he has written the patch
yet :)
>
> Then, when a handle is returned to the pool it is deleted, instead of adding
> it back to the pool.
BTW very soon engines will own their Cursor objects and will be free to reuse
them.
> 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 would say that long term this will be optional, based on what the engine
requires.
> OK, this make things a lot simpler! Indeed, if we don't need to support LOCK
> TABLE then external_lock() can be removed altogether.
Tried removing the external_lock() right now and seeing if any issues pop up?
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
