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 23:31:00 GMT


James Taylor commented on PHOENIX-4605:

{quote}My understanding is that before this feature we only support Tephra, we now supporting
both Tephra and Omid.
That's the goal, but this patch just sets the groundwork. It makes it so that a Phoenix table
stores the TransactionProvider and allows transaction providers to coexist at runtime. The
transaction provider is instantiated now based on the tables involved. Note that the goal
isn't to allow multiple transaction providers to be in use for the same transaction (that'll
produce an error), but just to allow them to be independently used. The next patch (well underway
by [~ohads]) is to implement the OmidTransactionProvider.
{quote}I saw you removed, What are
these two used for and how are we replacing the them.
Yes, these were removed, along with the PhoenixTransactionalTable interface. They're not necessary
as they were extending HTableInterface without adding any new methods. Essentially, a transaction
provider has to provide their own HTableInterface implementor that tracks what's necessary
(that's what Tephra does with it's TransactionAwareHTable). So the PhoenixTransactionalTable
interface is not needed.

{quote}FlappingTransactionIT and TransactionIT are we also going to include Omid?
Yes, the patch that'll come next will parameterize the transactional unit tests and run them
for both Tephra and Omid to ensure they have the same behavior.

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

View raw message