[ https://issues.apache.org/jira/browse/PHOENIX-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16434878#comment-16434878 ]
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 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)