Yeah, #1323 was intentionally applied to only a subset of transaction options. In particular, the only options that I added were the ones I could make a good case for as something that made sense to apply to all transactions (like retry limit). So, for example, we’d probably never want to add the
set_next_write_no_conflict_range option globally.
But I think it would be reasonable to add more. The change (at an implementation level) was to add more fields to the
DatabaseContext struct and to use those values to initialize the transaction options, so adding more fields could make sense. The two that were the most questionably excluded were
set_read_lock_aware. The former in theory might make sense to disable globally and, in fact, is disabled globally already in Java as it’s called by
Database::createTransaction. Pushing that down might also make sense, though whether it’s safe kind of depends on the language bindings.
set_read_lock_aware option, in theory, maybe should be set globally so that if one has a locked cluster, one can set it up so that one can easily read stale data from it without having to set the option manually each time. (Though maybe this is less important in FDB 6 than FDB 5 because of multi-region configurations don’t require the option be set to read from secondary regions.) The problem is that
set_read_lock_aware is implemented by (1) setting
lock_aware and (2) disabling commits. And one can’t “undisable” commits, so you get a kind of strange database object back.
Which I guess brings me back to the original question. The only method that must actually throw an error to ensure the transaction is read-only is commit—all other write-related operations will just be buffered locally. (Except maybe some keys in the
\xff\xff keyspace? Maybe?) And the native client actually already has a way to disable commits (it’s used by
set_read_lock_aware) though it appears not to be settable by the user.
Unlike the proposed option, I don’t think it can be undone, so using it as a way of providing a “read-only be default” database might not work. But your client could implement something like “on transaction creation, if I am in a read only context, disable commits”, and the only awkward thing is that doesn’t play super well with how our retry loops work.