Kristian Nielsen <knielsen@knielsen-hq.org> writes:
Rich Prohaska <prohaska7@gmail.com> 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.