[
https://issues.apache.org/jira/browse/PHOENIX-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074618#comment-15074618
]
James Taylor commented on PHOENIX-2411:
---------------------------------------
No need to implement anything else because we'd share the same
TransactionContext which encapsulates the transaction already. This should
hopefully work fine for CDAP, but there's more required for supporting a load
balancer in front of the query server - we'd need the transaction manager to
persist the change set on the cluster keyed by the transaction ID as it
wouldn't be feasible to return this back to the client.
> 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)
