ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Rakov <ivan.glu...@gmail.com>
Subject Re: Transaction classes naming
Date Wed, 20 Dec 2017 15:52:57 GMT
As a person who tried to infer transactional behavior from listed 
classes, I completely agree.

Also, I'd like to pay additional attention to:

1) IgniteTxAdapter#near method. It returns true both for GridNearTxLocal 
(where "near" means originating node) and GridNearTxRemote (where "near" 
means near cache). This is extremely confusing, we should rename this 
method as well.

2) GridNear*Request/Response classes (including non-transactional ones). 
They incapsulate requests from originating to primary nodes, so we 
should consider renaming them to GridOriginating*Request/Response.

Best Regards,
Ivan Rakov

On 20.12.2017 18:18, Alexey Goncharuk 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?

View raw message