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