[
https://issues.apache.org/jira/browse/PHOENIX-4278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16295555#comment-16295555
]
James Taylor commented on PHOENIX-4278:
---------------------------------------
Ping, [~ohads]. This would be a good to do as part of the Phoenix/Omid
integration. This would cover local & global *mutable* secondary index
maintenance and *immutable* local secondary indexes. Immutable global secondary
indexes are already maintained on the client side. It's best if you execute
everything on the client side so that you can add the shadow cells after the
write to the commit table is successful (you'll have all the index row cells,
so it should work nicely).
Take a look at PhoenixTransactionalIndexer. The preBatchMutate call figures out
the index updates that are necessary, storing them in the
BatchMutateContext.indexUpdates member variable on the thread local (no thread
local would be required if this is done client side). The heart of the logic is
in getIndexUpdates() which is just making regular HBase API calls (which would
be fine to do from the client side for transactions since the transaction
system is ensuring we see a consistent state thus row locking is not required).
That method forks depending on if a JDBC rollback is being done (i.e.
MutationState.rollback) or a regular update is being performed.
I think with a little refactoring, we can share this code - it's all self
contained in PhoenixTransactionalIndexer currently.
> 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
>
> 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
(v6.4.14#64029)
