From: Konstantin Osipov <kostja@tarantool.org> To: tarantool-patches@freelists.org Cc: Georgy Kirichenko <georgy@tarantool.org> Subject: [tarantool-patches] Re: [PATCH v2 1/2] Journal transaction boundaries Date: Fri, 8 Feb 2019 19:56:47 +0300 [thread overview] Message-ID: <20190208165647.GC4588@chai> (raw) In-Reply-To: <7b72afb3f1a3479f1239fcbed936cc151b55f23c.1548153546.git.georgy@tarantool.org> * Georgy Kirichenko <georgy@tarantool.org> [19/01/22 15:45]: > Append txn_id, txn_replica_id and txn_last to xrow_header structure. > txn_replica_id identifies replica where transaction was started and > txn_id identifies transaction id on that replica. As transaction id > a lsn of the first row in this transaction is used. > txn_last set to true if it is the last row in a transaction, so we > could commit transaction with last row or use additional NOP requests > with txn_last = true ans valid txn_id and txn_replica_id. > For replication all local changes moved to xrows array tail to form > a separate transaction (like autonomous transaction) because it is not > possible to replicate such transaction back to it's creator. I think we should not need txn_replica_id at all. Let's discuss. And I also thought we decided to drop txn_last? Having both txn_last and txn_id seems redundant. We could set txn_id to the last LSN of this txn, that would make txn_last unnecessary too, while giving us easy to track transaction boundaries. What about adding something like "write concern" to xrow header at the same time, so that we can select sync property individually for each transaction? > > As encoding/deconding rules assumed: > 1. txn_replica_id is encoded only if it is not equal with replica > id. This might have point because of replication trigger > 2. txn_id and txn_last are encoded only for multi-row transaction. > So if we do not have txn_id in a xstream then this means that it > is a single row transaction. > This rules provides compatibility with previous xlog handling. > -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov
next prev parent reply other threads:[~2019-02-08 16:56 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-22 10:57 [tarantool-patches] [PATCH v2 0/2] Transaction boundaries in replication protocol Georgy Kirichenko 2019-01-22 10:57 ` [tarantool-patches] [PATCH v2 1/2] Journal transaction boundaries Georgy Kirichenko 2019-01-28 12:58 ` Vladimir Davydov 2019-01-29 10:09 ` Георгий Кириченко 2019-01-29 11:00 ` Vladimir Davydov 2019-01-31 7:34 ` Георгий Кириченко 2019-01-31 8:19 ` Vladimir Davydov 2019-01-31 14:25 ` Георгий Кириченко 2019-01-31 14:54 ` Vladimir Davydov 2019-02-01 9:31 ` Георгий Кириченко 2019-01-28 13:00 ` Vladimir Davydov 2019-01-28 13:08 ` [tarantool-patches] " Vladislav Shpilevoy 2019-02-08 16:56 ` Konstantin Osipov [this message] 2019-01-22 10:57 ` [tarantool-patches] [PATCH v2 2/2] Transaction support for applier Georgy Kirichenko 2019-01-28 13:35 ` Vladimir Davydov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190208165647.GC4588@chai \ --to=kostja@tarantool.org \ --cc=georgy@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='[tarantool-patches] Re: [PATCH v2 1/2] Journal transaction boundaries' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox