atom feed14 messages in[jr3] MVCC
FromSent OnAttachments
Jukka ZittingFeb 17, 2010 9:06 am 
Alexander KlimetschekFeb 17, 2010 11:12 am 
Johann SorelFeb 17, 2010 12:58 pm 
Alexander KlimetschekFeb 17, 2010 1:57 pm 
Alexander KlimetschekFeb 17, 2010 1:58 pm 
Johann SorelFeb 17, 2010 2:51 pm 
Justin EdelsonFeb 17, 2010 7:51 pm 
Thomas MüllerFeb 17, 2010 11:43 pm 
sorelFeb 18, 2010 12:45 am 
Stefan GuggisbergFeb 18, 2010 2:34 am 
Alexander KlimetschekFeb 18, 2010 4:44 am 
Marcel ReuteggerFeb 18, 2010 2:24 pm 
Thomas MüllerMar 8, 2010 5:37 am 
Alexander KlimetschekMar 8, 2010 9:38 am 
Subject:[jr3] MVCC
From:Jukka Zitting (
Date:Feb 17, 2010 9:06:01 am


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?