Have you looked at TDB? This note seems to be SDB-centric in expectations.
As implemented Iterators require that if there is a change to the underlying data store the iterator must fail. Thus any write cancels all reads.
In TDB, Iterators from different transactions can exist at the same time and continue to iterate. They do not throw exceptions or fail on change outside the transaction - the changes simply aren't seen; writes do not cancel reads.
The use of iterators block updates making the use of graphs in high frequency read/write
In TDB, different versions of the database exist at the same time. Iterators do not block later writers or commits.
4. Serializable requests
within this isolation prohibit concurrent read/write, similar to the
current situation. Pro: absolute consistency. Cons: lower concurrency
TDB is fully serializable and allows concurrency, including concurrency between multiple versions of the database. TDB is not 2PL (SS2PL) based; it's MVCC (multi-version currency control). (By "MVCC", I mean a path-copying immutable datastructure style, not the multi-entry-version-id style - "MVCC" is used in both contexts.)
Locking a subgraph does not stablize query results. Queries can involve pattern negation (NOT EXISTS, MINUS). OPTIONALs also can depend on the absence of triples. Read-repeatable would also need to track read-repeatable-no-result.