Andrew Wong has posted comments on this change. ( http://gerrit.cloudera.org:8080/17431 )
Change subject: KUDU-2612 automatically flush sessions on txn commit ...................................................................... Patch Set 2: (4 comments) http://gerrit.cloudera.org:8080/#/c/17431/2//COMMIT_MSG Commit Message: http://gerrit.cloudera.org:8080/#/c/17431/2//COMMIT_MSG@22 PS2, Line 22: So, I opted : not to perform the consistency check as a part of KuduSession::Apply(), : rather relying on the logic of KuduSession::Flush() and : KuduSession::FlushAsync() methods instead. > This means that the check performed in StartCommit() is best-effort, i.e. i This is true even for Commit() (synchronous), right? Once calling commit, users can still apply more ops to each session? I don't think it's worth being more strict here -- if this pops up as an issue with real users, they can complain and we can address it. At the very least, any post-commit flushes will already result in op errors, and I think that is reasonable behavior. http://gerrit.cloudera.org:8080/#/c/17431/2/src/kudu/client/client-test.cc File src/kudu/client/client-test.cc: http://gerrit.cloudera.org:8080/#/c/17431/2/src/kudu/client/client-test.cc@7433 PS2, Line 7433: ASSERT_OK(session->SetFlushMode(KuduSession::MANUAL_FLUSH)); I do find it a bit odd for us to be implicitly flushing on Commit() even if a user has specified MANUAL_FLUSH mode. My impression of this mode is that the user has requested full control of all flushing matters. Given FlushMode() isn't constant, how would you feel about doing a best effort check for MANUAL_FLUSH mode, and calling some KuduSession::FlushForCommit() that takes into account the flush mode, only performing a flush in one of the AUTO modes? http://gerrit.cloudera.org:8080/#/c/17431/2/src/kudu/client/client.h File src/kudu/client/client.h: http://gerrit.cloudera.org:8080/#/c/17431/2/src/kudu/client/client.h@385 PS2, Line 385: awaits for the nit: either "awaits the" or "waits for the". Same below. http://gerrit.cloudera.org:8080/#/c/17431/2/src/kudu/client/transaction-internal.cc File src/kudu/client/transaction-internal.cc: http://gerrit.cloudera.org:8080/#/c/17431/2/src/kudu/client/transaction-internal.cc@198 PS2, Line 198: // It's a rare case, but nothing prevents to call session.reset() or : // session.swap(nullptr) for a transactional session in the user code. Doesn't this just replace the pointer in the scoped_refptr instance with a nullptr, and not affect other instances of KuduSession*? I.e. if a user-code caller were to call my_session.swap(nullptr), wouldn't that only affect that instance of the scoped_refptr `my_session` and not other references to the same underlying session? -- To view, visit http://gerrit.cloudera.org:8080/17431 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I2480129a99fb19d16868e14f9b9e33c83e3d8e7f Gerrit-Change-Number: 17431 Gerrit-PatchSet: 2 Gerrit-Owner: Alexey Serbin <[email protected]> Gerrit-Reviewer: Alexey Serbin <[email protected]> Gerrit-Reviewer: Andrew Wong <[email protected]> Gerrit-Reviewer: Grant Henke <[email protected]> Gerrit-Reviewer: Kudu Jenkins (120) Gerrit-Comment-Date: Fri, 14 May 2021 01:07:14 +0000 Gerrit-HasComments: Yes
