The Bobo Persistent Object System, release 2.0

This package includes a set of modules that together provide an extensible persistent object system.

This is not a database system, although it can be extended to provide database semantics.

For information on differences between BoboPOS 2 and BoboPOS 1 and for infoprmation on recent releases, see the release notes.

Important notes on BoboPOS 2:

Note:

BoboPOS is not suitable for use with CGI. If you use BoboPOS, you should use a long-running publishing mechanism like PCGI or Medusa.

Usage in a Nutshell

import PickleDictionary and Persistence from the BoboPOS package.

Persistent Objects

Persistent objects are objects that provide necessary behavior to interact with the persistent object system. Each persistent object is stored in a separate database record.

There is very little the application programmer must be aware of to make application objects persistent.

Transactions

The Bobo persistent-object system includes a simple transaction manager. A transaction manager manages movement of objects between memory and disk storage. It provides an important property, atomicity. Atomicity assures that a changes made during a transaction are made permanent if a transaction completes and are undone if a transaction is aborted. Transaction boundaries are defined by invoking transaction begin and commit operations.

When a transaction manager is installed, it installs a global function, get_transaction() to retrieve a per-thread transaction manager. The current Bobo release supports a single-threaded transaction model so only one thread may have a transaction model.

The get_transaction function is installed as a global variable so that applications like Bobo can interact with it without making assumptions about the transaction manager implementation. This allows alternate transaction managers to be used without modifying Bobo.

Application programs don't store or retrieve objects other than root objects. It is the transaction managers job to decide when objects most be loaded or saved. The only responsibility of the application programmer is to:

Defining root objects

To make objects persistent, we need to create a containment hierarchy rooted in an object that is contained in a PickleDictionary:

           db=PickleDictionary(lib+'/var/Data')
           if db.has_key('Trinkets'):
               trinkets=db['Trinkets']
           else:
               trinkets=db['Trinkets']=Trinkets()
               get_transaction().commit()

In this example, we have a root object trinkets that all other persistent objects will be (posibly indirectly) contained by.

Note the use of the get_transaction().commit() to notify the transaction system that objects may be saved.

Defining Transaction Boundaries

Transaction objects define three methods:

begin(info)

define the beginning of a transaction.

The argument info provides transaction meta-data that is currently ignored.

Note that begin implicitly aborts any changes made since the last commit or abort.

commit()

Make changed performed in the transaction permanent

abort()

Undo all changes made since the previous commit or abort.

In Bobo applications, Bobo automatically calls these methods before and after processing HTTP requests.

For additional information

See the Providing Persistence for World-Wide-Web Applications.

And see the examples given in the Bobo tutorial.