As discussed already before, switching from the current design where
all writes essentially block all concurrent repository access to a
MVCC design that decouples all read access from concurrent writes
would help us solve a number of performance bottlenecks. In addition
to the performance improvements the MVCC design avoids many of the
internal synchronization and cache invalidation mechanisms we have and
thus could help reduce complexity and avoid potential concurrency
Taken to the extreme we could even use MVCC to avoid the troublesome
situation where subsequent calls to a method like Property.getString()
return different values or may even start throwing exceptions because
of the actions of another session. With MVCC we could ensure that the
content seen by a session remains constant until an explicit
Session.refresh() call is made or something like an observation
listener is registered.
Implementing this will be somewhat tricky as it affects large areas of
the core code and spans over the current PersistenceManager boundary.
Also the interaction with things like the search index or other
resources stored outside the main persistence mechanism is non-trivial
(but see the thread on uniform persistence).