[ 
https://issues.apache.org/jira/browse/PHOENIX-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16434878#comment-16434878
 ] 

James Taylor commented on PHOENIX-4605:
---------------------------------------

V1 patch passes all unit tests. With this patch:
 * Both Tephra and Omid transactional tables can coexist (though not in the 
same transaction).
 * The transaction provider is determined by metadata on the table 
(TRANSACTION_PROVIDER table property)
 * The transaction interface (TAL) was simplified
 * The setup of the DML fence is a method in PhoenixTransactionContext. It's 
called only before sending a batch of rows to the server.
 * The transaction client and transaction server service are broken out into 
their own classes and their lifecycles match the lifecycle of 
ConnectionQueryServices (shared connection to cluster).

Please review, [~ohads] and/or [~tdsilva].

> Support running multiple transaction providers
> ----------------------------------------------
>
>                 Key: PHOENIX-4605
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4605
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Assignee: James Taylor
>            Priority: Major
>         Attachments: PHOENIX-4605_v1.patch, PHOENIX-4605_wip1.patch, 
> PHOENIX-4605_wip2.patch, PHOENIX_4605_wip3.patch
>
>
> We should deprecate QueryServices.DEFAULT_TABLE_ISTRANSACTIONAL_ATTRIB and 
> instead have a QueryServices.DEFAULT_TRANSACTION_PROVIDER now that we'll have 
> two transaction providers: Tephra and Omid. Along the same lines, we should 
> add a TRANSACTION_PROVIDER column to SYSTEM.CATALOG  and stop using the 
> IS_TRANSACTIONAL table property. For backwards compatibility, we can assume 
> the provider is Tephra if the existing properties are set to true.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to