Transparent Persistence
+ Transaction Processing…
Smalltalk is pure object-oriented programming for complex business and technical applications, but the benefits of this can be lost in the well-known ‘impedance mismatch’ with relational databases.
The VOSS open source virtual object storage system extends Smalltalk with integrated database management, providing transparent multi-user access and transaction processing of persistent, versioned, Smalltalk objects directly accessible by normal programming, with efficient persistent Btree collection classes, including the multi-key/multi-value/key-set VirtualDictionarySet for aggregation and query-building.
- Scalable multi-process, multi-image, network access to distributed objects
- ACID transactions with two-phase commit, logging and rollforward crash recovery
- Persist clustered complexes of any Smalltalk classes except block closures
- Historical object versioning, MVRC repeatable read, MVCC concurrency control
- Automatic object locking with transaction rollback & retry on deadlock time-out
- Automatic change detection, no lock conflicts with sub-transactions, short read-locks
- Multi-key/multi-value/key-set Btree VirtualDictionarySet with query-building methods
- Continuation Transactions manage alternative futures e.g. multiple web page states
- Long Continuation Transactions may be persisted prior to ultimate commit/rollback
- Web server / application process rendezvous
- Distributed copying, parented copying, identity-exchange, checkout, read-only etc
- Concurrent variable-rate incremental foreground & background garbage collection
- Up to 150 logged transactions per second on desktop hardware
- Terabyte 64-bit object id and addressing default, configurable up to 128-bit
- Dual Licensing - Open Source GPLv3 and/or Supported Commercial Licence
…Seamless Smalltalk Solutions 
(C) Logic Arts Ltd 2008
VirtualDictionarySet (a virtualized subclass of DictionarySet) is the workhorse collection class to use for aggregation of objects in a VOSS database. Typically, all the objects in a DictionarySet will be of the same class (e.g. Employee, Department, Project, Order, Invoice etc), but not necessarily.
DictionarySet allows its elements to be indexed by any number of single-valued and/or multi-valued key-selector unary messages (e.g. #employeeNumber (single-valued), #lastName (multi-valued), #deptNumber (a foreign key in Employees), #deptNumber (primary key in Departments) etc), as required by the application.
Complex queries are built by sending messages such as <#for: #lastName equals: ‘Smith’> to the DictionarySet, to which the DictionarySet returns a set of its elements meeting that criterion. There is an example of a complex query here. Read the rest of this entry »
Join the forum discussion
on this post The previous release (3.145.01) introduced buffered transaction logging, in which a log archive daemon process archives the contents of the log buffer at specified intervals, increasing the maximum commit rate to 50 transactions per second on desktop hardware. This new release 3.145.02 allows for log archiving to be disabled, further increasing transaction throughput, for example up to 150 logged random create/inserts per second into a VirtualDictionary of 10 million objects (depending on cache settings, and with no concurrent garbage collection). Read the rest of this entry »
Join the forum discussion
on this post When an object is added to a DictionarySet (or VirtualDictionarySet), it is added to each of the DictionarySet’s component AutoDictionaries, each of which sends its defined unary message selector to the object to obtain the key at which it is to be inserted.
If the object returns a VOKeySet or VOKeyCollection (which should also normally be a set of unique keys) then the object is added into that AutoDictionary at each of those keys; this may be useful, for example, if the DictionarySet elements are published books or papers, each of which may have been written by several contributing authors. The consequence of this, however, is that the DictionarySet would no longer be a set, as a book having three authors will be present three times, once at each author key, and this could cause unexpected behaviour in DictionarySet>>do: and other enumeration methods. Read the rest of this entry »
Join the forum discussion
on this post 