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 TephraTransactionTable.java, 
OmidTransactionTable.java. 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 
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: 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_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

Reply via email to