belliottsmith commented on code in PR #10:
URL: https://github.com/apache/cassandra-accord/pull/10#discussion_r988615334
##########
accord-core/src/main/java/accord/messages/Apply.java:
##########
@@ -54,15 +63,59 @@ public Apply(Node.Id to, Topologies topologies, TxnId
txnId, Txn txn, Key homeKe
this.result = result;
}
+ @VisibleForImplementation
+ public Apply(Keys scope, long waitForEpoch, TxnId txnId, Txn txn, Key
homeKey, Timestamp executeAt, Deps deps, Writes writes, Result result)
+ {
+ super(scope, waitForEpoch);
+ this.txnId = txnId;
+ this.txn = txn;
+ this.homeKey = homeKey;
+ this.executeAt = executeAt;
+ this.deps = deps;
+ this.writes = writes;
+ this.result = result;
+ }
+
+ static Future<Void> waitAndReduce(Future<Void> left, Future<Void> right)
Review Comment:
> you need this extra state and cas operations to do it, and once you’ve
added all that, the efficiency argument becomes a lot thinner.
Except I think all of this extra work needs to be done for `Future` too? I'm
pretty sure the correct approach here is simply using the `Future` as a carrier
for a callback? So in this case we have two sides of the safety coin: the side
we pass to the `Executor` which can be easily encapsulated safely (or done for
us by the `Executor` even more cheaply), and the consumer side which I think
will be identical, as we need to manage the concurrency of multiple
asynchronous results being accumulated in the object that is reducing them, and
we need to do it without blocking the thread?
> With a callback, there are more options:
I don't think there are? The only affordance I see here is the `trySuccess`
and `tryFailure` methods, but we can readily have a very lightweight class (a
single boolean) that a callback can accept (or be passed to as a lambda) that
ensures this isn't a problem.
Obviously there's a huge spectrum of possible functionality/performance
points, and we have to be selective so as not to overwhelm our lingua franca. I
think we might have room for a couple of additional points in the spectrum
though: lightweight `Future` objects designed to only support at most one
follow-up action (either a caller waiting on the result, or a listener of some
kind); and better callback support.
But I think we should always reach for callbacks first, and only upgrade to
`Future` where we find it specifically is well justified by the call-site, so
that the trade-offs are well considered and we don't become overly dependent on
the additional machinery when it isn't needed (the caller I think can always be
made equivalent to `Future`, as discussed above). I think by far the majority
of use-cases in Cassandra (esp. until we get virtual threads) are best
expressed as single submit/consume transactions with an object accumulating one
or more outcomes - and callbacks fit this niche perfectly.
I guess we have accidentally trodden on a minor landmine about project code
style and direction :)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
