James Taylor commented on PHOENIX-3860:

You mean after PHOENIX-4278, right? For local indexes, we'll want to continue 
to process updates on the server-side - that's an oversight on my part. The 
reason is that we know the updates to the index table will be a local write and 
we can generate the write on the server side. Having a separate RPC and sending 
the updates across the wire would be tremendously inefficient. On top of that, 
we need the region boundary information which we have already in the 
coprocessor, but would need to retrieve it on the client side (with a likely 
race condition too if a split occurs after we retrieve it).

I filed PHOENIX-4619 for this additional work.

> Implement TAL functionality for Omid
> ------------------------------------
>                 Key: PHOENIX-3860
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-3860
>             Project: Phoenix
>          Issue Type: Sub-task
>            Reporter: Ohad Shacham
>            Assignee: Ohad Shacham
>            Priority: Major
> Implement TAL functionality for Omid in order to be able to use Omid as 
> Phoenix's transaction processing engine. 
> To support the integration jira [OMID-82] was opened that encapsulates all 
> Omid related development for Phoenix.

This message was sent by Atlassian JIRA

Reply via email to