You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "James Taylor (JIRA)" <ji...@apache.org> on 2015/12/04 22:07:11 UTC

[jira] [Updated] (PHOENIX-2411) Allow Phoenix to participate as transactional component

     [ https://issues.apache.org/jira/browse/PHOENIX-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Taylor updated PHOENIX-2411:
----------------------------------
    Fix Version/s: 4.7.0

> 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
>             Fix For: 4.7.0
>
>
> 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)