[
https://issues.apache.org/jira/browse/TEPHRA-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16162614#comment-16162614
]
ASF GitHub Bot commented on TEPHRA-240:
---------------------------------------
Github user poornachandra commented on a diff in the pull request:
https://github.com/apache/incubator-tephra/pull/47#discussion_r138239467
--- Diff:
tephra-core/src/main/java/org/apache/tephra/TransactionSystemClient.java ---
@@ -89,21 +89,38 @@
*
* @param tx transaction to verify
* @param changeIds ids of changes made by transaction
- * @return true if transaction can be committed otherwise false
- * @throws TransactionSizeException if the size of the chgange set
exceeds the allowed limit
- * @throws TransactionNotInProgressException if the transaction is not
in progress; most likely it has timed out.
+ *
+ * @throws TransactionSizeException if the size of the change set
exceeds the allowed limit
+ * @throws TransactionConflictException if the change set has a conflict
with an overlapping transaction
+ * @throws TransactionNotInProgressException if the transaction is not
in progress; most likely it has timed out
*/
- boolean canCommitOrThrow(Transaction tx, Collection<byte[]> changeIds)
throws TransactionFailureException;
+ void canCommitOrThrow(Transaction tx, Collection<byte[]> changeIds)
+ throws TransactionNotInProgressException,
TransactionConflictException, TransactionSizeException;
--- End diff --
Would declaring `TransactionFailureException` here help in making the API
resilient to some future changes - in-case we need to add new exceptions to
indicate a transaction failure?
> TransactionConflictException should contain the conflicting key and client id
> -----------------------------------------------------------------------------
>
> Key: TEPHRA-240
> URL: https://issues.apache.org/jira/browse/TEPHRA-240
> Project: Tephra
> Issue Type: Bug
> Reporter: Andreas Neumann
> Assignee: Andreas Neumann
> Fix For: 0.13.0-incubating
>
>
> Often transaction conflicts are hard to explain. Having the conflicting key,
> or even the name of the client that performed the concurrent update would
> greatly help debug.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
