phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Assigned] (PHOENIX-2411) Allow Phoenix to participate as transactional component
Date Fri, 04 Dec 2015 21:07:11 GMT

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

James Taylor reassigned PHOENIX-2411:
-------------------------------------

    Assignee: James Taylor

> 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
>
>
> 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)

Mime
View raw message