Archive for August, 2008
When an object is added to a DictionarySet (or VirtualDictionarySet), it is added to each of the DictionarySet’s component AutoDictionaries, each of which sends its defined unary message selector to the object to obtain the key at which it is to be inserted.
If the object returns a VOKeySet or VOKeyCollection (which should also normally be a set of unique keys) then the object is added into that AutoDictionary at each of those keys; this may be useful, for example, if the DictionarySet elements are published books or papers, each of which may have been written by several contributing authors. The consequence of this, however, is that the DictionarySet would no longer be a set, as a book having three authors will be present three times, once at each author key, and this could cause unexpected behaviour in DictionarySet>>do: and other enumeration methods.
For this reason, when a DictionarySet is created it is automatically initialized with a baseDictionary on the key selector #yourself, which is thus a set, and DictionarySet>>do: etc. all operate on this baseDictionary.
This presents an opportunity for optimisation: since if it is known that none of the DictionarySet elements will ever return a VOKeySet or VOKeyCollection of keys, the baseDictionary is unnecessary and may be removed at any time, in an ordinary transaction, by the method DictionarySet>>removeBaseDictionary.
Subsequent transactions which add/remove objects to/from the DictionarySet will thus be faster.
When there is no baseDictionary, DictionarySet>>do: etc. operate on one of the component AutoDictionaries chosen at random.
jc
Join the forum discussion
on this post Queries in a VOSS odbms are written in Smalltalk and may therefore be of arbitrary complexity, addressing an arbitrary semantic network of persistent objects. However, to simplify the most common kinds of queries, it is recommended that VirtualDictionarySet be used as the general-purpose Collection for the major aggregations of application entities in the database.
A DictionarySet may index its elements on any number of single-valued and/or multi-valued unary key selector messages, which may be added or removed at any time by ordinary (though potentially large) transactions, and DictionarySet uses these to provide efficient query-building methods which return subsets of its contents, allowing more complex queries to be built by union and intersection of these sets.
A previous article noted the optimisation possible by using #for:equalsNoCopy: which returns the actual virtual set within the VirtualDictionarySet, instead of #for:equals: which returns a copy of it, when there is no intention to add or remove elements to or from the returned answer set. This article concerns optimisation of queries using #for:between:and:.
The set returned by this method may be used to build queries in the usual way, by union and intersection with other sets, but it is as well to know that it is typically slower than #for:equals:. This is because, for example in the query: journeys for: #startDate between: aDate and: bDate, the answer set is constructed by finding (efficiently) the integer indexes of the (nearest etc) elements at the keys aDate and bDate and then enumerating the keys between those two, using integer index access each time, to add their values into the constructed answer set, rather than simply answering an existing set of multiple values at a key (or the element at a single-valued key in a constructed set by itself).
If, therefore, the partial answer set from #for:between:and: is large, it may be more efficient to intersect the sets returned by other parts of the query first, and enumerate that smaller result with #select: to return the subset of those elements which meet the range criterion.
jc
Join the forum discussion
on this post The VOSS collection, DictionarySet, and therefore also its subclass VirtualDictionarySet, follows the normal Smalltalk practice of returning a new collection when asked for a subset of its elements, just as when using Collection>>select:.
However, when sending a DictionarySet one of the most commonly used query messages, #for:equals: (as in Journeys for: #month equals: ‘August’) the required elements will already be in an explicit virtual set in one of its component VirtualMultiValuedAutoDictionaries. For consistency, however, those elements are all added into a constructed answer set, and this takes time. For this reason, an optimisation is provided as the alternative method DictionarySet>>for:equalsNoCopy: which returns the actual virtual set from the database.
It’s safe to do this only if the application does not change that returned set, as that would be a subversive change to just that one of the DictionarSet’s component AutoDictionaries, which the DictionarySet keeps synchronised when adding or removing elements; however that can be avoided with care, and anyway cannot happen in a read-only transaction.
From a concurrency point of view, it’s also as well to remember that this returned virtual set will be locked each time a message is sent to it in a read-only transaction having #isolationDegree=2 (short read-locks), whereas when using #for:equals: the returned set is not virtual, it’s a real set of virtual objects, and only its elements will be locked when sent messages, which may make some difference to concurrency. If the transaction’s #isolationDegree=3 all locks are held until the transaction rollsback or commits, so it wouldn’t make any difference anyway.
jc
Join the forum discussion
on this post A user has contributed the following optimisation, which will be included in the next release.
Add the following method:
VORefPrivate>>isVOKeyCollection
“Private”
^false
The addition of this method improves concurrency by eliminating unnecessary object locking of virtual objects which are being used as keys in a VirtualDictionary or VirtualDictionarySet.
When virtual objects are used as keys they behave as identity keys, as only their global object IDs are compared, and both components of this (the virtual object ID prefixed by the ID of the virtual space in which it exists) are present in every VORef proxy for that object, hence the key comparison message is not forwarded to the object itself and so the object is not locked into the transaction.
However, this was undermined some time ago by the addition of the key collection feature, as the message #isVOKeyCollection is sent to the candidate key by all the virtual dictionary addition, removal and inclusion methods, and this is forwarded to the object, which correctly returns <false> (from the default Object>>isVOKeyCollection), but leaves the object locked in the current transaction.
The above new method prevents this, and will be included in the next release.
The reason that the candidate key is tested with #isVOKeyCollection is that if the key answers <true> then it is a collection of keys, and the argument object is added (etc) at each of the elements of that collection of keys. An example of this might be when a published book is to be keyed on each of its collection of authors, each of whom is also an object in the database with their own (changeable) names, attributes and relationships.
jc
Join the forum discussion
on this post 