VOSS 3.1

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

VOSS 3.145.00.09 (beta) is now available for download.

This release has changed commit behaviour of sub-transactions within a Continuation Transaction, such that if such a sub-transaction has a non-nil #dateAndTimeToRead (i.e. it sees only read-only historical versions of objects) then, if it is committed, it commits all the objects then locked in its parent Continuation Transaction (including its own objects), whether changed or not - the changed ones as changed, the unchanged ones as at their respective states at that #dateAndTimeToRead - as changes to their current (most recent, read/write) versions. (In the previous release (beta .08) only those objects which the sub-transaction had changed were committed.)

This new behaviour is more intuitively correct and useful, since it commits (”pastes forward”) the sub-transaction’s complete historical view, which could be, for example, an earlier product design configuration etc, with changes, as a new timestamped view. The previously current versions of those objects, now overwritten, still exist in their read-only historical states timestamped at their respective previous commits.

Because a transaction’s #dateAndTimeToRead may be any value, not just some actual commit timestamp, that now-overwritten world view is still there to see as at the appropriate timestamp, and could, if desired, be re-established as current simply by committing that historical view forwards with no changes but a new commit timestamp.

Join the forum discussion on this post