[
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)