Virtual Objects
Virtual Objects & Persistence
VOSS extends Smalltalk with persistent object storage, transparent access and transaction management. A structure (also referred to as a ‘complex’, or ‘granule’) of objects typically representing an application entity such as a Customer or Order, may be told to become virtual by sending its root object the message #becomeVirtualIn: This causes the whole complex to be moved into the specified virtual space in persistent disk storage as a single entity, with any existing references to the original root object changed to reference the root of the virtualized complex. Alternatively, and more efficiently, objects may be created as virtual by sending #newVirtualIn: to the class (instead of #new). Virtual objects may consist of instances of almost any class except block closures and parts of the Smalltalk environment itself.
Each virtual complex has a single identity, and this natural clustering, or granularity, of virtual objects contributes significantly to overall performance. Much as the majority of telephone calls are local, the majority of Smalltalk messages are sent between local objects, and messages between the components of a complex are processed at the same speed as messages to real objects. The application designer has full control over granularity according to which objects are sent the #becomeVirtualIn: message.
The purpose of virtual objects is to allow applications to be written using normal Smalltalk application classes and programming, as though for a single user with all objects in the image, using new virtual Btree Collection classes for aggregation, with minimal additional consideration for the definition of each transaction. Virtual objects may be referenced by variables of all kinds: Global, Class, Temporary or Instance, in other real or virtual objects and they are fully functional in response to normal programming, with no need for separate database manipulation language nor transformation to and from other representations such as relational tables.
VOSS minimizes network traffic and instantiation overhead by caching virtual objects in each connected image which has sent them a message, refreshing them transparently from the file server only as required (according to commit timestamp/sequence number) if they have been changed by another transaction in the meantime. The cache size can be set individually for each connected image and can be as large as memory permits.
