[
https://issues.apache.org/jira/browse/PHOENIX-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16192200#comment-16192200
]
James Taylor commented on PHOENIX-4232:
---------------------------------------
bq. Could you please explain the snapshot read scenario, your solution, and why
Tephra works correctly in this case?
Tephra doesn't need it's own RegionScanner because it doesn't have to worry
about scanning a separate commit table. The state is essentially passed through
the TransactionVisibilityFilter from the client (i.e. the time stamps to skip
for invalid/inflight transactions). In fact, Tephra could even do the index
maintenance from the client side (see PHOENIX-4278).
bq. Regarding reread the shadow cells, assuming I would like to run Omid
standalone with server side filtering. I can get the region from
RegionCoprocessorEnvironment and run a get at the server side. I assume that
will work, not sure how efficient will it be. What do you think?
That's what I was thinking as it provides a good way to abstract all this
interaction away. However, let's brainstorm a bit on what it would take to do
this on the client-side. HBase is not very happy when you do RS->RS RPCs. If
it's rare that shadow cells are absent, perhaps we could have the server throw
an exception back to the client when this happens and then the client could
perhaps retry after getting whatever state is missing from the commit table and
passing it along. The downside is that it'd be more complicated.
> Hide shadow cell and commit table access in TAL
> -----------------------------------------------
>
> Key: PHOENIX-4232
> URL: https://issues.apache.org/jira/browse/PHOENIX-4232
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: Ohad Shacham
> Labels: omid
>
> Omid needs to project the shadow cell column qualifier and then based on the
> value, filter the row. If the shadow cell is not found, it needs to perform a
> lookup in the commit table (the source of truth) to get the information
> instead. For the Phoenix integration, there are likely two TAL methods that
> can be added to handle this:
> # Add method call to new TAL method in preScannerOpen call on coprocessor
> that projects the shadow cell qualifiers and sets the time range. This is
> equivalent to the TransactionProcessor.preScannerOpen that Tephra does. It's
> possible this work could be done on the client side as well, but it's more
> likely that the stuff that Phoenix does may override this (but we could get
> it to work if need be).
> # Add TAL method that returns a RegionScanner to abstract out the filtering
> of the row (potentially querying commit table). This RegionScanner would be
> added as the first in the chain in the
> NonAggregateRegionScannerFactory.getRegionScanner() API.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
