The Chandler Project Blog

Chandler’s repository enables concurrent and versioned access to the items it stores. The repository keeps the history of all changes made to items over their lifetime. This history can be used to replay or revert changes made to an item. It makes undoing committed transactions possible. It makes automated merging of different versions possible.

OSAF chose a non-locking transaction model for Chandler’s repository. This model allows for arbitrarily long concurrent transactions as no items are locked for exclusive access. All changes to items are done in memory and are committed to persistent storage when the application is ready to do so. Of course, such uncontended long concurrent transactions have a higher incidence of version conflicts happening during commit. If the same item was changed by two or more concurrent transactions, only the first one to commit its changes is guaranteed to succeed. Chandler’s approach is to attempt to merge these versions whenever possible and to raise an understandable exception to the end-user for manual resolution or cancelling of the changes otherwise.

Each repository transaction is implemented by a repository view. Every thread of execution has a current view created and opened by default. A view manages instances for a set of items that are on-demand loaded as they are called by the program using them. Each view keeps track of the changes made to the item instances it controls until they are committed. If two or more views are managing an instance for the same item, each is maintaining a distinct python instance for it, simplifying threaded programming somewhat. Since views commit the changes for their own item instances independently of each other, they typically present different versions of the items they manage. After a view has committed its changes successfully, it catches up with all the changes other views had committed until that time and it becomes the view of latest version.

With care, views can be managed independently of threads. The repository createView() method lets developers create as many views as they need. Before it can be used, a view needs to first be made current for the thread that is going to use it with the setCurrentView() method. Once a view is no longer needed it should be closed with the closeView() method in order to release all the resources it is using.

Views are also caches for item instances. As long as an item instance remains valid in a view, that view will return the same instance for all repository operations returning that item. By default, an item instance is invalidated – marked stale – when that item changed in another view and its instance needs refreshing after a commit. Unless an item instance is pinned in memory, it is not guaranteed to be valid beyond the next commit operation done by the view managing it. As a view’s cache grows, it will prune the cache of its least-used item instances when its instance count reaches a certain threshhold. Pinned item instances cannot be pruned because pruned item instances are invalidated as well; item instance pinning should therefore be used sparingly.

This entry was posted on Monday, June 7th, 2004 at 10:06 pm and is filed under chandlerdb. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.