Database Management for Smalltalk

Transparent Persistence

+ 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 virtual object storage, providing persistence, 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

Mon 14th Apr 2008   03:04 PM
posted by John Clapperton

‘Garbage’, in an object-oriented database system, means objects which have become unreachable because references from other objects have been removed by the application, and which are therefore to be removed to reclaim storage space. The garbage collector (’GC’) in VOSS is a ‘Baker’ design, similar in concept to the garbage collector in Smalltalk-80, which can be run in foreground and/or background modes of which more later.

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.

Read the rest of this entry »


Join the forum discussion on this post
Thu 3rd Apr 2008   07:04 PM
posted by John Clapperton

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.

Read the rest of this entry »


Join the forum discussion on this post
Thu 7th Feb 2008   06:02 PM
posted by John Clapperton

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.) Read the rest of this entry »


Join the forum discussion on this post
Wed 9th Jan 2008   06:01 PM
posted by John Clapperton

Where do you keep your behavior? Normalised in the application domain objects? In non-domain transaction-performing classes? Some of each? I seem to remember this question being touched on once long ago in Digitalk’s Compuserve forum, but never since. Read the rest of this entry »


Join the forum discussion on this post