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 Questions have been asked about what each transaction is doing in the 40tps benchmark mentioned in the previous post.
The test ‘application’ is a loop which each time around commits a transaction which creates two new virtual objects, each of which is an Array of two elements, the first a Float, the second a String of 65 characters, which is added into a VirtualDictionary using the integer part of the Float as the key. The application updates a scrolling window on each commit. Garbage collection is switched off, MVRC/MVCC Versioning is switched off. The log archive delay interval is 1000ms. The test is run for 30 seconds and the dictionary size is about 20000 elements.
For comparison, if the loop is set to add four such objects in each transaction, the commit rate falls to 30tps. Or if just one object is created and added to the VirtualDictionary the commit rate increases to 50tps (with the log archive delay interval reduced to 750ms, so as not to trigger re-initialization of the log archive process, which by default happens when there are 100 transactions in the log buffer file).
John
Join the forum discussion
on this post New in this release, together with the Continuation Transactions, Persistent (”Long”) Continuation Transactions, Web Rendezvous, MVRC & MVCC features already in the 3.1 beta, is buffered transaction logging.
With a background log archive daemon which activates at specified intervals (by default 1500 milliseconds) to archive the contents of the log buffer file, buffering increases the maximum commit rate to 40 transactions per second on desktop hardware, which file flushing previously limited to about four. If the archive interval is set to zero (from the Control Panel or by program) the archive daemon terminates and each transaction is logged and flushed on commit, as in previous releases. With the transaction log on a separate drive or network server, rollforward of secure backups of the logged virtual spaces allows recovery from general power outage and from head crash or malicious damage at a single machine.
Rollforward recovery applies all log entries archived since the backup, followed by all (self-validating) well-formed log entries readable from the log buffer file. If log buffer flushing is enabled then recovery of all committed transactions is assured (though reducing the maximum commit rate to about 15 transactions per second on a typical IDE drive), but is otherwise dependent on the behaviour of the particular disk drive on power outage during a write append in the last sector of the buffer file, which is read and re-written in whole, even though the operating system called an appending write. (AFAIK it is not possible to control an IDE drive at a sufficiently low level to allow implementation of ping-pong appends).
VOSS 3.145.01is available for download here under the GPLv3 open source project licence, please mailto:mail@logicarts.com re supported commercial licensing.
John
Join the forum discussion
on this post 