Kristian Nielsen <kniel...@knielsen-hq.org> writes:
> Rich Prohaska <prohas...@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.
_______________________________________________
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help : https://help.launchpad.net/ListHelp
