VOSS 3.1

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

New release 3.045.26 is available for download. This fixes a problem when full disk volume is encountered during background garbage collection (as distinct from foreground GC during transaction commit). The same fix has been applied in 3.145.00.11 (beta).

Join the forum discussion on this post

VOSS 3.145.00.10 (beta) is now available for download.

New feature in this release is Persistent Continuation Transactions.

An open VOContinuationTransaction which has committed any number of alternative futures for its set of objects in continuation sub-transactions may now itself be persisted, or persisted & deactivated which removes the live transaction from the image, allowing log-off and shutdown.

Whilst the persisted continuation transaction exists, it and all its objects are persistently set read-only in the name of that transaction. Whilst deactivated it may be re-activated from the Control Panel or by program message sending, to re-create the live open transaction.

Persistent transactions are useful in design or what-if type of applications, where transactions may extend over days of revision and re-working of different saved possible final states, until a final commit is chosen.

Persisting a VOContinuationTransaction stores in the current virtual space (in a private dictionary in the stateDictionary) a virtual object complex which is a representation of the open VOContinuationTransaction, as a VOPersistedContinuationTransaction containing the same virtual objects. The same complex also includes a representation of its owner VOSession and its virtualObjectPark dictionary and contents, as a VOPersistedSession.

By default, every committing VOConSubTransaction persists its parent VOContinuationTransaction within the same commit; this default may be changed by the class method:

  VOContinuationTransaction persistConTxnOnSubTxnCommitDefault: aBoolean.

The public instance methods of VOContinuationTransaction offer further options. For example, VOContinuationTransaction>>persistAndDeactivate persists the receiver and removes it from the image, setting persistent read-locks on its VOPersistedContinuationTransaction and contents.

If all open VOContinuationTransactions in an image have been persisted and deactivated, the image may log-off and shutdown if desired.

Whilst a VOContinuationTransaction is active (i.e. exists, open, in the image), but has not yet been persisted, its contents are locked by volatile cache and object table file (.vot) record locks in the same way as in an ordinary  transaction. When persisted, the persistent read-locks are additional, but incidental from the point of view of other Process’s transactions (in the same or other images). However, when an open VOContinuationTransaction has been deactivated, it no longer exists in the image and its volatile locks are released; other Process’s transactions may then see such objects, but the persistent read-locks will block them from committing any changes to those objects (or the VOPersistedContinuationTransaction itself).

At the application level, the database may be considered to be in an inconsistent state (this is not something which any DBMS can determine, it is a matter for the application designer and/or user; consider, for example, work in progress in a CAD design for a gearbox or building), and objects which were write-locked in the open VOContinuationTransaction will now be only read-locked and therefore visible to other Processes in their deemed inconsistent state. However, this situation may be managed, since such locks may be tested by the method:

  VORefPublic>>isReadOnlyForPersistedTransaction

and/or by checking the startTimestamp (id) of each extant VOPersistedContinuationTransaction in each virtual space returned by the method:

  VOManager>>persistedContinuationTransactionsOrIDs

so that other Process’s transactions may choose to see the database as at a specified #dateAndTimeToRead (or equivalent integer #timestampToRead) pre-dating any or all extant persisted continuation transactions. If transaction versioning is globally enabled (set by VOManagerManager>>versioning: aBoolean, or from the Control Panel) then all historical states prior to the continuation transaction(s) may be seen.

Persisted instances of VOPersistedContinuationTransaction are shown in the Control Panel, and may be (re)activated by menu there, or by one of the following messages to the single LocalVOSSServer global instance of VOSSServer.

  VOSSServer>> activatePersistedContinuationTransaction: aPersistedContinuationTxn
or
  VOSSServer>> activatePersistedContinuationTransactionID: anInteger in: aVOManager

Download here and test-drive this in the tutorial.

Join the forum discussion on this post