Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <CABDss3gOXssipZGRC-ytna_RoEP7xuQET8S4oiw2z6YsEEcTFg@mail.gmail.com>
References: <CABDss3gOXssipZGRC-ytna_RoEP7xuQET8S4oiw2z6YsEEcTFg@mail.gmail.com>
From: Vladimir Ozerov <vozerov@gridgain.com>
Date: Wed, 20 Dec 2017 18:39:44 +0300
Message-ID: <CAGt6o8nkhx21zRvzjF0e4+Wv8RWnCnCMf-kXjMjSLNowQCZ64Q@mail.gmail.com>
Subject: Re: Transaction classes naming
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary="94eb2c094e6886e6040560c76486"
archived-at: Wed, 20 Dec 2017 15:39:52 -0000

--94eb2c094e6886e6040560c76486
Content-Type: text/plain; charset="UTF-8"

+1

On Wed, Dec 20, 2017 at 6:18 PM, Alexey Goncharuk <
alexey.goncharuk@gmail.com> wrote:

> Igniters,
>
> As I review transaction-related PRs and communicate with other fellow
> Igniters, I realized that our transaction classes naming became
> inconsistent and almost impossible to explain to a new contributor. A few
> examples:
>
> 1) We have a GridNearTxLocal class, but Near in the name does not
> necessarily mean that this transaction has to do with the near cache. It
> may or may not, depending on the cache configuration. Near in this case
> only stands for _originating_ node transaction. This is also reflected in
> many messages, such as Near*Request, where near stands for a message sent
> from an originating node to the primary node.
> 2) We have GridNearTxRemote and GridDhtTxRemote classes. First, near here
> always means near cache, as near remote transaction will only be created
> for near-enabled caches. Second, Remote in the class names stands for
> backups (affinity backups or temporarily near-reader backups). On the other
> hand, requests sent from primary to backups are named Dht*Request.
>
> All in all, the naming is extremely confusing. For a person who hasn't seen
> the evolution of transaction classes over time, it is impossible to infer
> or even assume what these classes stand for.
>
> I would like to kick off a discussion on new transaction classes and
> messages naming (especially as we started developing MVCC which most likely
> will introduce additional TX classes).
>
> How about:
> OriginatingTx for transaction created on originating node
> PrimaryTx for transaction created on primary nodes, but not the originating
> node
> BackupTx for transaction created on backup nodes
> NearTx for transaction created to update near cache
>
> Thoughts?
>

--94eb2c094e6886e6040560c76486--