[
https://issues.apache.org/jira/browse/PHOENIX-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074597#comment-15074597
]
Thomas D'Silva commented on PHOENIX-2411:
-----------------------------------------
+1 LGTM, are you going to implement the method to return the (potentially new)
transaction state in a different JIRA?
> Allow Phoenix to participate as transactional component
> -------------------------------------------------------
>
> Key: PHOENIX-2411
> URL: https://issues.apache.org/jira/browse/PHOENIX-2411
> Project: Phoenix
> Issue Type: Improvement
> Reporter: James Taylor
> Assignee: James Taylor
> Fix For: 4.7.0
>
> Attachments: PHOENIX-2411.patch, PHOENIX-2411_v2.patch,
> PHOENIX-2411_v3.patch
>
>
> Frameworks such as Cask's CDAP support a means of individual components to
> participate in a transaction. To support this, Phoenix would need to:
> - Provide a means of passing in the serialized state of a transaction as a
> connection property. An easy way to do this is to base64 encode the byte[] of
> the serialized transaction.
> - Provide a statement or statements to run and flush any uncommitted data
> after execution. The caller could use the Statement.addBatch(String sqlStmt)
> multiple times and call Statement.executeBatch() to run more than one
> statement at a time.
> - Return back the potentially new transaction state (as checkpointing may
> have been required as a result of running the batch of statements).
> In addition, for our query server to remain stateless, we'll need this type
> of behavior, as it's possible that a load balancer in front of the query
> server would route an UPSERT or DELETE to a different query server node.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
