maria-discuss team mailing list archive

[Rich Prohaska <prohaska7@xxxxxxxxx>]

On Wed, Aug 10, 2016 at 8:02 AM, Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>
wrote:

> 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.
>

I agree.

IMO, the implementation could add a lock wait for callback to the TokuFT
layer (see set_lock_timeout_callback for a similar method).  The TokuFT
lock manager would call this function (if it exists).  The TokuDB layer
would implement the callback and call the appropriate mysql API that
handles the replication logic.  There is enough information to map tokuft
transaction id's to mysql client id's (see below).


>
> 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.
>

The tokudb information schema needs to map a tokuft transaction id to a
mysql client id, so the code attaches the mysql client id to the tokuft
transaction object via set_client_id calls, and gets the mapping via
get_client_id calls.  There should be a function that maps a mysql client
id to a mysql THD (if there isn't one already).

The tokuft lock manager lock can ensure that the lock tree state is not
changes when the wait for callback is called.  This means that granted
locks can not be removed, which means that the transaction that owns the
locks can not be destroyed, which means that the owning THD can not go away.


> 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.
>