phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-4605) Support running multiple transaction providers
Date Thu, 12 Apr 2018 03:16:00 GMT


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
 * 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

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

> Support running multiple transaction providers
> ----------------------------------------------
>                 Key: PHOENIX-4605
>                 URL:
>             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,
> 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

View raw message