phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (PHOENIX-4605) Support running multiple transaction providers
Date Thu, 12 Apr 2018 04:35:00 GMT

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

James Taylor edited comment on PHOENIX-4605 at 4/12/18 4:34 AM:
----------------------------------------------------------------

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].

Couple of questions too, Ohad:
 * Do we need PhoenixTransactionalTable? What purpose does it serve?
 * How does Omid handle a table with a TTL specified? The standard HBase one is problematic
as it gets confused with the cell timestamp not matching wall clock time. Tephra has it's
own table property which we use under-the-covers when a TTL is specified on a table (FYI,
you can use the ALTER TABLE command to set hbase metadata on a Phoenix table). It'd be convenient
if Omid used the same property name. You could probably use the same code that Tephra uses
in the compaction coprocessor hook.


was (Author: jamestaylor):
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)

Mime
View raw message