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 capnproto+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/capnproto/160291441337.22919.1464428527358410126%40localhost.localdomain.
