[ https://issues.apache.org/jira/browse/PHOENIX-4278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16356694#comment-16356694 ]
ASF GitHub Bot commented on PHOENIX-4278: ----------------------------------------- Github user ohadshacham commented on a diff in the pull request: https://github.com/apache/phoenix/pull/291#discussion_r166868712 --- Diff: phoenix-core/src/main/java/org/apache/phoenix/schema/PTableImpl.java --- @@ -1038,32 +1038,21 @@ public void setValue(PColumn column, byte[] byteValue) { @Override public void delete() { newMutations(); - // we're using the Tephra column family delete marker here to prevent the translation - // of deletes to puts by the Tephra's TransactionProcessor - if (PTableImpl.this.isTransactional()) { - Put put = new Put(key); - if (families.isEmpty()) { - put.add(SchemaUtil.getEmptyColumnFamily(PTableImpl.this), TransactionFactory.getTransactionFactory().getTransactionContext().getFamilyDeleteMarker(), ts, - HConstants.EMPTY_BYTE_ARRAY); - } else { - for (PColumnFamily colFamily : families) { - put.add(colFamily.getName().getBytes(), TransactionFactory.getTransactionFactory().getTransactionContext().getFamilyDeleteMarker(), ts, - HConstants.EMPTY_BYTE_ARRAY); - } - } - deleteRow = put; --- End diff -- No, since instead of writing directly the family deletion marker we perform a regular delete operation using the transaction processor. The transaction processor writes this family deletion marker and in here we just check for its existence. > Implement pure client side transactional index maintenance > ---------------------------------------------------------- > > Key: PHOENIX-4278 > URL: https://issues.apache.org/jira/browse/PHOENIX-4278 > Project: Phoenix > Issue Type: Improvement > Reporter: James Taylor > Assignee: Ohad Shacham > Priority: Major > > The index maintenance for transactions follows the same model as non > transactional tables - coprocessor based on data table updates that looks up > previous row value to perform maintenance. This is necessary for non > transactional tables to ensure the rows are locked so that a consistent view > may be obtained. However, for transactional tables, the time stamp oracle > ensures uniqueness of time stamps (via transaction IDs) and the filtering > handles a scan seeing the "true" last committed value for a row. Thus, > there's no hard dependency to perform this on the server side. > Moving the index maintenance to the client side would prevent any RS->RS RPC > calls (which have proved to be troublesome for HBase). It would require > returning more data to the client (i.e. the prior row value), but this seems > like a reasonable tradeoff. -- This message was sent by Atlassian JIRA (v7.6.3#76005)