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.
