[
https://issues.apache.org/jira/browse/PHOENIX-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated PHOENIX-2411:
----------------------------------
Description:
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.
was:
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.
- Optionally provide a means of getting back the potentially new transaction
state (as checkpointing may have been required as a result of running the batch
of statements).
> 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
>
> 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)