Quoting Smurf En Drek (2020-10-16 20:46:37)
> To avoid this, I assume the methods should be made aware of them being
> pipelined so they can pass a set of locks on some keys around between
> method calls so that everything stays consistent, even with pipelined
> calls. Are there Cap'nProto features that would help me with this?
Probably what I would do here would be to explicitly model transactions
in the interaces, e.g. you might have something like:
interface Database {
startReadOnlyTx @0 () -> (tx :ReadOnlyTx);
startReadWriteTx @1 () -> (tx :ReadWriteTx);
}
interface ReadOnlyTx {
get @0 (key :Data) -> (value :Data);
}
interface ReadWriteTx extends ReadOnlyTx {
set @0 (key :Data, value :Data);
commit @1 ();
# Commit the transaction. To roll back/abort, drop the transaction
# object without committing.
}
...you could then put the logic to acquire locks and whatnot in the
implementations of ReadOnlyTx/ReadWriteTx.
> get(get(mycatname)+"_color)
Note that promise pipelining itself only allows you to call methods and
pass values around; if you want to do something like string
concatenation you will have to either (1) suffer the round trip, or (2)
expose methods on the server for the relevant operations; the calculator
example may be of interest here for an example of how you might model
this:
https://github.com/capnproto/capnproto/blob/master/c%2B%2B/samples/calculator.capnp
--
You received this message because you are subscribed to the Google Groups
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/capnproto/160291441337.22919.1464428527358410126%40localhost.localdomain.
