Andrey, Good point. Even though it is not as confusing as near-remote naming, I agree that this should be fixed as well.
2017-12-20 18:59 GMT+03:00 Andrey Kuznetsov <stku...@gmail.com>: > Alexey, > > And what do you think about 'Adapters' in transaction heirarchy? This term > looks really obfuscating for new contributor, since in fact they are not > adapters for something but abstract superclasses. > > 2017-12-20 18:18 GMT+03:00 Alexey Goncharuk <alexey.goncha...@gmail.com>: > > > 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? > > > > > > -- > Best regards, > Andrey Kuznetsov. >
