Hi,

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 issues.

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).

Should we do this? How?

BR,