From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 14 Jun 2019 10:58:16 +0300 From: Vladimir Davydov Subject: Re: [tarantool-patches] [PATCH v3 11/14] txn: introduce asynchronous txn commit Message-ID: <20190614075816.kueipndcjr4euxtg@esperanza> References: <697f3313f6ad706a71c74ec259c0ea37d2702184.1560112747.git.georgy@tarantool.org> <20190613143400.uminobjjgnkeleat@esperanza> <1668523.8YztoT5jxX@home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1668523.8YztoT5jxX@home.lan> To: =?utf-8?B?0JPQtdC+0YDQs9C40Lkg0JrQuNGA0LjRh9C10L3QutC+?= Cc: tarantool-patches@freelists.org List-ID: On Thu, Jun 13, 2019 at 10:45:18PM +0300, Георгий Кириченко wrote: > On Thursday, June 13, 2019 5:34:00 PM MSK Vladimir Davydov wrote: > > On Sun, Jun 09, 2019 at 11:44:40PM +0300, Georgy Kirichenko wrote: > > > diff --git a/src/box/txn.c b/src/box/txn.c > > > I don't see why we need to have in_txn() in on_commit/rollback triggers. > > Could you please point me? > Unfortunately lua on_commit triggers use it (because of vshard requirements) > and I'm don't see the right way to remove it. Okay, I see. Let's add a comment please that this is needed for Lua triggers. Just curious, how can it possibly use it? > > > > > diff --git a/src/box/wal.c b/src/box/wal.c > > > index e868a8e71..eff48b4fe 100644 > > > --- a/src/box/wal.c > > > +++ b/src/box/wal.c > > > @@ -272,6 +272,8 @@ tx_schedule_f(va_list ap) > > > > > > struct journal_entry *req = > > > > > > stailq_shift_entry(&writer->schedule_queue, > > > > > > struct journal_entry, fifo); > > > > > > + if (req->on_done_cb != NULL) > > > + req->on_done_cb(req, req->on_done_cb_data); > > > > > > req->done = true; > > > fiber_cond_broadcast(&req->done_cond); > > > > Why do we need cond if we have a callback? Can't we wake up the awaiting > > fiber from the callback? > The condition and the done variable is required the time when all transaction > data could be purged. I think we could purge async transactions right in the callback. > Definitely it could not be done while on_done_cb because > we will lost transaction status in this case. I think there are some ways to > handle this but I think the solution would be too complicated. I don't get what you mean by "loosing transaction status". Could you elaborate please? > I use the callback to process txn finalization and call on_commit/on_rollback > trigger one of them signals an applier fiber to collect transaction and > determine replication state. Why can't we collect the transaction right from the completion callback? I think we could propage a failure to applier via on_rollback trigger. I something wrong with it?