maria-discuss team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx> writes:

> Rich Prohaska <prohaska7@xxxxxxxxx> writes:
>
>> Is TokuDB supposed to call the thd report wait for API just prior to a
>> thread about to wait on a tokudb lock?
>
> If I wanted to look into implementing this, do you have a quick pointer to
> where in the TokuDB code I could start looking? Like the place where lock
> waits are done? (I have not worked with the TokuDB source before, though I

I took just a quick look at the code, in particular lock_request.cc:

  int lock_request::start(void) {
      txnid_set conflicts;
      ....
      r = m_lt->acquire_write_lock(m_txnid, m_left_key, m_right_key, &conflicts, m_big_txn);
      if (r == DB_LOCK_NOTGRANTED) {

It seems to me that at this point in the code, what is required is to call
thd_report_wait_for() on each element in the set conflicts, and that should
be about it.

Some mechanism will be needed to get from TXNID to THD, of course. A more
subtle problem is how to ensure that those THDs cannot go away while
iterating? I'm not familiar with what kind of inter-thread locking is used
around TokuDB row locks.

But it looks like a proof-of-concept patch for TokuDB optimistic parallel
replication might be fairly simple to do.

I also noticed that TokuDB does not support handlerton->kill_query() (so
KILL cannot break a TokuDB row lock wait). That should be fine, the KILL
will be handled when the wait finishes (or if _all_ transactions are waiting
on the row locks of each other, then a normal TokuDB deadlock detection will
handle things).

 - Kristian.