Alexey Serbin has posted comments on this change. ( http://gerrit.cloudera.org:8080/16044 )
Change subject: KUDU-2612 p2: introduce transaction status management ...................................................................... Patch Set 2: (9 comments) I did a quick first pass. Overall looks good, some nits. Will get back tomorrow after digesting it a bit :) http://gerrit.cloudera.org:8080/#/c/16044/2/src/kudu/transactions/status_entry.h File src/kudu/transactions/status_entry.h: http://gerrit.cloudera.org:8080/#/c/16044/2/src/kudu/transactions/status_entry.h@105 PS2, Line 105: map Does it make sense to use unordered_map here instead? If GetParticipantIds() is the only place where ordering is needed, I think it might make sense to sort the result container if GetOrCreateParticipant() is called much more often than GetParticipantIds(). http://gerrit.cloudera.org:8080/#/c/16044/2/src/kudu/transactions/status_entry.cc File src/kudu/transactions/status_entry.cc: http://gerrit.cloudera.org:8080/#/c/16044/2/src/kudu/transactions/status_entry.cc@39 PS2, Line 39: scoped_refptr<ParticipantEntry> participant; nit: why not to have this defined and assigned at the same line? http://gerrit.cloudera.org:8080/#/c/16044/2/src/kudu/transactions/status_entry.cc@53 PS2, Line 53: vector<string> ret; nit: add ret.reserve(participants_.size()); http://gerrit.cloudera.org:8080/#/c/16044/2/src/kudu/transactions/status_entry.cc@54 PS2, Line 54: for (const auto& id_and_prt : participants_) { : ret.emplace_back(id_and_prt.first); : } nit: consider using AppendKeysFromMap() (it has a specialization for std::vector, so it's possible to drop ret.reserve()) http://gerrit.cloudera.org:8080/#/c/16044/2/src/kudu/transactions/status_manager-test.cc File src/kudu/transactions/status_manager-test.cc: http://gerrit.cloudera.org:8080/#/c/16044/2/src/kudu/transactions/status_manager-test.cc@383 PS2, Line 383: ASSERT_OK(txn_manager_->FinalizeCommitTransaction(kTxnId2)); Does it make sense to verify how BeginCommitTransaction() works on already committed transaction? http://gerrit.cloudera.org:8080/#/c/16044/2/src/kudu/transactions/status_manager-test.cc@391 PS2, Line 391: ASSERT_OK(txn_manager_->RegisterParticipant(kTxnId1, ParticipantId(1), kOwner)); Does it make sense to add a scenario trying to register a participant when a transaction hasn't begun yet? http://gerrit.cloudera.org:8080/#/c/16044/2/src/kudu/transactions/status_manager.h File src/kudu/transactions/status_manager.h: http://gerrit.cloudera.org:8080/#/c/16044/2/src/kudu/transactions/status_manager.h@19 PS2, Line 19: stdint.h nit: use <cstdint> instead http://gerrit.cloudera.org:8080/#/c/16044/2/src/kudu/transactions/status_manager.cc File src/kudu/transactions/status_manager.cc: http://gerrit.cloudera.org:8080/#/c/16044/2/src/kudu/transactions/status_manager.cc@123 PS2, Line 123: RETURN_NOT_OK(status_tablet_.AddNewTransaction(txn_id, user)); What if there was a race and there is a record with higher transaction ID already persisted? Should TxnStatusManager handle that or that will be client handling this error case? In either case, and for the error case above: where does the caller get an idea what ID it should try next? http://gerrit.cloudera.org:8080/#/c/16044/2/src/kudu/util/cow_object.h File src/kudu/util/cow_object.h: http://gerrit.cloudera.org:8080/#/c/16044/2/src/kudu/util/cow_object.h@437 PS2, Line 437: // Helper to manage locking on the metadata protected by a CowLock. Thank you for adding this doc! -- To view, visit http://gerrit.cloudera.org:8080/16044 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I371bb200cf65073ae3ac7cb311ab9a0b8344a636 Gerrit-Change-Number: 16044 Gerrit-PatchSet: 2 Gerrit-Owner: Andrew Wong <[email protected]> Gerrit-Reviewer: Alexey Serbin <[email protected]> Gerrit-Reviewer: Kudu Jenkins (120) Gerrit-Comment-Date: Tue, 23 Jun 2020 04:43:52 +0000 Gerrit-HasComments: Yes
