Paul McCullagh wrote:
Hi Toru,
On Dec 7, 2009, at 3:31 AM, Toru Maesaka wrote:
Great to hear another use-case where knowing a statement type in
advance is useful :)
Yes, generally I need to know the following:
- If I have a update type statement (i.e. whether the statement modifies
rows).
- Whether I need a table lock (examples: ALTER TABLE, TRUNCATE, CHECK).
But, Paul, doesn't this depend on the engine itself? I mean, some
engines can do (some types of) ALTER TABLE without taking a table lock.
So, is this request really for whether the kernel thinks a table-level
lock is necessary, or is it really just for a descriptor of the
statement type?
And, if it really does just boil down to the statement type, then how do
we deal with the reality that Brian speaks about -- that statement type
will be pluggable, and how do we deal with future statement types for
pluggable engines?
Is a reasonable solution to pass to engines a sort of "statement
traits"? So, instead of passing ALTER_TABLE, CREATE_TABLE, UPDATE,
DELETE, etc, we instead pass a std::bitset<> (or uint64_t for C folks)
containing traits of the statement such as:
MODIFIES_DATA
MODIFIES_DEFINITION
etc, etc
And then to deal with transaction locking concerns, just add a method to
Cursor:
void Cursor::setTransactionIsolationLevel(enum enum_tx_isolation);
Cheers!
Jay
- If we have a SELECT FOR UPDATE.
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 :)
I've taken notes from our discussion the other day. I'm planning on
working on it when I finish testing through my current progress of
BlitzDB.
Great! :)
For now, I'm happy with Jay's advise of using
current_session().
Cheers,
Toru
On Sat, Dec 5, 2009 at 5:59 AM, Brian Aker <[email protected]> wrote:
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
--
Paul McCullagh
PrimeBase Technologies
www.primebase.org
www.blobstreaming.org
pbxt.blogspot.com
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
