+ Transaction Processing…

 
Smalltalk is pure object-oriented programming for complex business and technical applications, but these benefits can be lost in the mismatch between language and database. The VOSS open source database management system extends Smalltalk with persistent virtual object storage, transparent access and transaction management.

• Multi-process, multi-image & multi-machine access to distributed objects
• ACID transactions with logging and rollforward crash recovery
• Continuation Transactions manage multiple web page states & what-if futures (v3.1)
• Web server / application process rendezvous (v3.1)
• Automatic object locking and transaction retry on time-out
• Automatic object change detection, no lock conflicts with sub-transactions
• Multi-key/multi-value Btree DictionarySet and other virtual collections
• Time-slice MVRC repeatable read and MVCC with short read-locks
• Distributed copying, parented copying, identity-exchange, object checkout etc.
• Concurrent background & foreground garbage collection
• Terabyte 64-bit object id and addressing default, configurable up to 128-bit
• Dual Licensing - Open Source GPLv3 and Supported Commercial

…Seamless Smalltalk Solutions

Unlike the mark-sweep design, which truly is a ‘garbage collector’, the Baker design would be better characterised as a ‘good object preserver’ which copies all reachable objects within a virtual space back and forth from one ’semi-space’ to another, deleting everything left behind on each flip. This has consequences for database design, administration, and the choice of GC settings, to tune for maximum transaction throughput and minimum time offline.

Know which space your objects are in.

In a database design using multiple virtual spaces, the most important thing to know is that when the VOSS GC flips it preserves only those objects in a virtual space which are (indirectly) reachable from the rootDictionary of that virtual space or from the image in which the GC is then running (in the case of uncommitted new objects). In other words, any object in virtual space ‘A’ which is referenced only by an object in virtual space ‘B’, though it will behave normally whilst present, will not be preserved when the GC flips virtual space ‘A’. Or in other words again, reference(s) from object(s) in another virtual space alone are not sufficient to preserve an object from the GC of the virtual space in which it exists. In its systematic copying, the GC does not follow references to objects outside the virtual space which it is scanning.

This situation must be avoided, as after such a flip, those objects would become instances of VOUndefinedObject, and later magically become some arbitrary new object when the id number of that apparently garbage object in space ‘A’ was re-allocated to a new object, having spent some days, weeks or months on space ‘A’s free id list.

The simplest way to keep this right is always to use one of the explicit variants of the message to virtualize an object, preferably on creation, which specify the location explicitly, for example:

  myObject := MyClass newVirtualIn: aVOManager.

The non-specific variants, for example:

  myObject := MyClass newVirtual.

virtualize the new instance in the current virtual space of the current process, i.e. the virtual space which hosts the last object to have received a message in the current process.
 

Why use multiple virtual spaces?

One reason for distributing a database across multiple virtual spaces may be that some parts of the database are static, whilst others are volatile - subject to frequent update and new object creation - and in this case unnecessary GC processing can be avoided by suitable partitioning of the database, so that the more static virtual space is GC’d less frequently, if at all.
 

Foreground or Background Garbage Collection?

Foreground GC scans and saves a specified number of reachable objects as an addendum to  each transaction commit, before that transaction’s changes are physically written to disk, to minimise disk activity. The effect, to the user, is that each transaction commit takes longer than it otherwise would, depending on the number of objects it is set to scan.

Background GC runs as one or more separate background processes, effectively dummy users committing null transactions, which each do some GC as above. Within each image, background GC processes commit their invisible dummy transactions once every user-specified time delay, by default 3000 milliseconds, and scan a user-specified number of objects each time (which may be different from the foreground scan-rate). Foreground and background GC may run concurrently.

The advantage of background GC is that it utilises CPU cycles in between application transaction commits; the disadvantage is that it adds to the total amount of disk flushing activity, whereas foreground GC-writes are flushed within the same transaction commit - which was going to happen anyway.

Foreground GC is preferable if the application consists mainly of frequent transactions which are a short time in the preparation before commit (i.e. whilst the application has control); background GC is preferable if transactions are less frequent and/or a long time in the preparation, especially open-ended interactive transactions, when background GC can go on whilst the user is thinking.

If the operational objective is continuous operation with no downtime for GC, then, on average, the GC should scan objects for preservation at a rate equal to the average rate of object creation or modification per transaction, so that there is no backlog of new and/or changed objects to be scanned when a GC flip is requested, to delete the garbage and start the reverse trek. This is most simply achieved by setting a high GC scan rate, so that the GC is at or nearly at the end of its task, ready to flip, after each transaction. The visual GC Progress Indicator shows how close to 100% the GC is at any time.

Foreground GC does not attempt to flip automatically, and so will not perform unnecessarily eager copying of the reachable objects - if there is nothing more to scan, before it has scanned its quota, it stops and lets the transaction commit. Background GC, however, may be requested to flip the virtual space every time it reaches 100%, and if so set, then it is possible for the GC to churn the entire contens of the virtual space back & forth at a high rate, even if there are no garabage objects at all, wasting CPU cycles and disk flushing time. The Database Administrator should set background GC run frequency (i.e. milliseconds delay between each run) and the number of objects to be scanned in each run, to meet operation requirements, considering the applications’ average transaction size and frequency.

Note that a GC flip request (explicit or automatic) will succeed only if the image which is running the GC is the only image logged-on to that virtual space; this is because the GC has no knowledge of, and therefore cannot preserve, uncommitted non-garbage objects in another image.
 

24×7 uptime?

The actual flip of the GC is done with exclusive access to the virtual space, blocking all other activity on it, but it takes less than a second, so the eager GC strategy described above will allow continuous service uptime, save only for the need to log-off all but one image from time to time to allow the flip to take place.

Downtime for backup and possible hot-backup enhancement of VOSS will be the subject of a future post.

In practice, an application may have a greater transaction rate at some times of the day and week than at others, and it may be that such is the load during busy times that foreground and/or background GC rate and frequency may need to be changed to match. This may be done at any time, either via the Control Panel or programmed message-sending to the VOManager concerned, by a time-scheduled process if desired.

Join the forum discussion on this post

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

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

One of the benefits of a persistent object database is that not only static integrity constraints but arbitrarily complex procedure can be expressed just once in the appropriate application domain object, rather than being scattered and/or replicated in a number of external function oriented procedures - normalisation of procedure, in other words. However, the downside of this is that if an intensively used method is located in a domain class of which there are relatively few instances, then those objects may become locking hotspots which destroy concurrency, even though they themselves may not be changed, merely carrying transactional responsibility.

At the other extreme, locating transaction procedures in non-database objects which call only get & set methods in the domain objects, maybe with simple integrity constraint methods, imposes no additional constraint on concurrency, but at the cost of additional work during application design and modification, to ensure that update transactions are all consistent with each others’ implied integrity constraints.

Design by CRC cards (class, responsibility, collaboration) would seem to identify the theoretical location of transaction responsibility, but how does this work out in practice? Are there common patterns from which guidelines might be found for these design decisions?

Join the forum discussion on this post

A:  The choice is either:

1)  Get all user input, then validate and execute in a block transaction forked off in a background process,  or

2)  Use open-ended transactions, which allow the user to browse and twiddle, retaining all locks until rollback or commit. 

1) has the advantage that any number of windows can do this concurrently and also the user interface process is free to do other things whilst the background process is running.  However, it does mean that user input cannot be validated field by field as it is input by the user.  A separate read-only background block transaction could validate each user input, but then there is the possibility that another user may change objects after the validation transaction has released its locks and before the read-write transaction performs the update.

However, in some applications this may not matter, for example the user may enter a part number, immediately see a description retrieved by a read-only background block transaction, and continue so forth for the transaction as a whole; the specified part description could have been changed, or the part removed from the dictionary, in the meantime by another user, causing a rare error in the update transaction, but something which changes frequently, such as stock-on-hand, should be validated and updated all in the same transaction whilst locks are retained.

2)  (Use open-ended transactions, which allow the user to browse and twiddle, retaining all locks until rollback or commit.) Open-ended transactions are normally used only in the user interface process, so if running VOSS in non-interactive mode take care to set up the transaction attributes to handle lock time-outs as intended, (see VOTransaction>>rollbackOnTimeOut: aBoolean).  In interactive mode VOSS gives the user a dialog of choices on lock time-out.

Any process can have a tree of nested and sibling sub-transactions. Whenever a transaction is committed or rolled back its whole sub-tree goes the same way. It is therefore possible to create sibling sub-transactions (of ‘Top’, typically) for separate windows which may be separately committed or rolled back under the control of their respective window buttons.

Whenever a process sends a message to a virtual object it is locked on behalf of that process into that process’s current transaction, so each window is responsible for making its transaction current each time that window gets focus.  When a transaction commits or rolls back it removes all its objects from its collection of locked objects, but the actual lock on an object, held by the voSession on behalf of its process, is not released until the last remaining transaction which has a lock on it has committed or rolled back. Since all these transaction belong to the same process they share objects, i.e. they don’t wait for locks on objects locked by each other as they would for locks held by transactions belonging to other processes, so care is required if two windows (sharing the same User Interface Process) are sharing access to any objects, they can overwrite each others changes.

A transaction tree can be created in the Control Panel (* indicates the current transaction), or with test code like this:

  Smalltalk “set up some global variables”
    at: #TxnA put: nil;
    at: #TxnB put: nil;
    at: #QAZ put: nil.

Then evaluate the following one line at a time updating the Control Panel each time to see the effect

  TxnA := VOTransaction newNamed: ‘txnA’.
  TxnA superTransaction makeCurrent.
  TxnB := VOTransaction newNamed: ‘txnB’.
  TxnA makeCurrent.
  QAZ := (Array newVirtual: 1) atAllPut: $x.
  TxnB makeCurrent.
  QAZ “display in workspace (and gets the object into TxnB too)”
  TxnB commit.
  TxnA makeCurrent.
  QAZ
  QAZ atAllPut: $y.
  TxnA commit.
  TxnA := TxnB := QAZ := nil.

A:  An open-ended transaction is delimited by the execution of paired statements:

  VOTransaction newNamed: ‘Update customer’.     “starts a sub-transaction of the current transaction of the current process and makes it current”
  …
  …
  VOTransaction commit. “commits the current transaction of the current process”

or

  | aTxn |
  aTxn := VOTransaction new.
  aTxn name: ‘Update customer’.
  …
  …
  aTxn commit.

The paired statements do not have to be in the same method, but it is the programmer’s responsibility to ensure proper nesting.  The system ensures that there is always a default open-ended transaction called ‘Top’ for each process which has ever sent a message to a virtual object.  ‘Top’ is not normally used in applications, if objects are ever found in ‘Top’ it is usually a programming error.

With VOSS-on-client, open-ended transactions simplify the implementation of interactive transactions since the user interface process can access virtual objects directly and also return to input-watching during the transaction, with simple button-clicks for transaction start/commit/rollback. Multiple windows can have concurrently open sibling open-ended transactions in the user-interface process.

Block transactions are of the form:

  [:thisTxn |
    thisTxn name: ‘Update customer’. 
    “or name constructed via message to virtual object(s), must be done in transaction”
    …
    (some rollback condition) ifTrue: [^anObject]. “Any explicit return forces rollback”
    …
  ] atomicIfSucceed: [] ifFail: [].  “starts, executes and commits a sub-transaction of the current transaction of the current process”

These have the advantages of enforcing proper nesting, and by default will automatically rollback and retry on lock request time-out (lock requests are automatic).  Block transactions are also convenient to run in background processes and are therefore normal when VOSS is configured as a server.

A:  VOSS-on-client is conceptually simpler since the user interface and virtual objects can both be accessed directly by the application running on the client, but in this configuration all objects touched in a transaction travel over the network to the client. This configuration can be multi-user since any number of images on separate machines on a LAN can connect to the same virtual space(s) on file-server(s). However, it’s more vulnerable to crashes, as a desktop machine could be switched off in the middle of committing a transaction, which will block all access to the virtual spaces touched by that transaction until after a Database Administration person has performed a restart and backup (if the transaction was writing to the transaction log at that instant), or a rollforward recovery (if it was writing to (one of) the work virtual space(s) at that instant).

When a VOSS-enabled image is running on a server, the application serves remote clients by concurrent background processes in the image.  This keeps the entire transaction on the server, but means the application must communicate with its clients via byte string data transfer.  Virtual objects may be serialized for transmission and re-instantiation between client and server if the client is also running Smalltalk, but synchronization is the responsibility of the application.

A:  You don’t need to, but you can if you want to.  It’s entirely up to you how to organise the granularity; the only rule is that anything which is to be referenced by more than one virtual object must be a separate virtual object itself i.e. have been sent #madeVirtualIn: before assignment or #becomeVirtualIn: after assignment (but that’s slow).

If the OrderedCollection is small and frequently accessed then make it part of its parent virtual object i.e. don’t send it #madeVirtualIn:, but if it’s large or infrequently used you may prefer to make it a separate virtual object, so that it is not read from disk being part of its owner, only if sent a message; the elements of the OrderedCollection should themselves be separate virtual objects if they are referenced by any other virtual object, but if they are, for example short Strings that would be unnecessary and inefficient.  If in doubt, use a VirtualCollection and consider optimising to an OrderedCollection later, when the application is better understood.

VirtualCollection and VirtualDictionary etc are Btrees in which each Btree node is a separate virtual object, which is much more efficient for large collections, and not much slower for small ones.

A:  One virtual space in each disjoint set of virtual spaces used in an application must be designated as the location for the Transaction Log (flagged as ‘TL’ in the Control Panel), even if transaction logging is disabled, since transactions may include objects in any of that disjoint set which are connected to the image in which the transaction exists, and the TL space co-ordinates these.  If transaction logging is disabled then any space may be designated as the TL space, even if it contains application domain objects.  However if logging is enabled the TL space may contain only the Transaction Log; VOSS enforces this and any transaction which attempts to commit objects into the TL space will be forced to rollback if logging is enabled.

For full data integrity in the event of random power failures etc, logging should be enabled and a separate virtual space created and designated at TL space, preferably located on a different disk drive.

Logging is enabled like this:

  VOManagers logging: true.

VOManagers is a global variable holding the sole instance of VOManagerManager.

All virtual spaces connected to an image share the same TransactionLog since a transaction may include objects in any connected virtual space.