gnue/geas/doc odmg.txt

[Daniel E. Baumann]

CVSROOT:        /cvsroot/gnue
Module name:    gnue
Changes by:     Daniel E. Baumann <address@hidden>      02/03/27 00:04:38

Modified files:
        geas/doc       : odmg.txt 

Log message:
        Add notes for locking and concurrency control, transaction interface, 
and
        database interface.

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/geas/doc/odmg.txt.diff?tr1=1.11&tr2=1.12&r1=text&r2=text

Patches:
Index: gnue/geas/doc/odmg.txt
diff -c gnue/geas/doc/odmg.txt:1.11 gnue/geas/doc/odmg.txt:1.12
*** gnue/geas/doc/odmg.txt:1.11 Mon Mar  4 22:43:05 2002
--- gnue/geas/doc/odmg.txt      Wed Mar 27 00:04:38 2002
***************
*** 1968,1971 ****
  
          relationship list<Operand> the_operands
                            inverse Operand::operand_in;
!       };
\ No newline at end of file
--- 1968,2243 ----
  
          relationship list<Operand> the_operands
                            inverse Operand::operand_in;
!       };
! 
!   Locking and Concurrency Control
!   ===============================
!   - ODMG Object Model uses a conventional lock based approach to to
!   concurrency control
!   - approach procides mechanism for enforcing shared or exclusive
!   access to objects
!   - ODMS grants a lock only if no conflicting locks exist
!   - as a result access to persistent objects is coordinated across
!   multiple transactions, and a consistent view of the ODMS is
!   maintained for each transaction
!   - ODMG Object Model supports pessimistic concurrency control as its
!   default policy, but does not preclude an ODMS from supporting a wider
!   range of concurrency control policies
! 
!     Lock Types
!     ==========
!     - following locks are supported in the ODMG Object Model
!       - read
!       - write
!       - upgrade
! 
!     - read locks allow shared access to an object, write locks indicate
!     exclusive access to an object
!     - readers do not conflict with other readers, but writers conflict
!     with both readers and writers
!     - upgrade locks are used to prevent a form of deadlock that occurs
!     when two processes both obtain read locks on an object and then
!     attempt to obtain a write locks on that same object, deadlock is
!     avoided by initially obtaining upgrade locks, instead of read
!     locks, for all objects that intend to be modified, avoids any
!     potential conflicts when a write lock is later obtained to modify
!     the object
!     - locks follow the same semantics as those defined in OMG
!     Concurrency Control Service
! 
!     Implicit and Explicit Locking
!     =============================
!     - ODMG Object model supports both implicit and explicit locking
!     - implicit locks are locks acquired during the course of traversal
!     of an object graph
!       - e.g., read locks are obtained each time an object is accessed
!       and write locks are obtained each time an object is modified
!     - in case of implicit locks, no specific operation is executed in
!     order to obtain a lock on an object
!     - explicit locks are acquired by expressly requesting a specific
!     lock on a particular object, obtained by calling 'lock' and
!     'try_lock' operations defined in the Object interface
!     - read and write locks can be obtained implicitly, upgrade locks
!     must be acquired explicitly via 'lock' and 'try_lock'
! 
!     Lock Duration
!     =============
!     - by default all locks (read, write, and upgrade) are held until
!     the transaction is either committed or aborted, this prevents
!     dirty reads, non-repeatable reads, and phantoms.
! 
!   Transaction Model
!   =================
!   - programs that use persistent objects are organized into transactions
!   - transaction management is an important ODMS functionality, fundamental to
!   data integrity, shareability, and recovery
!   - and access, creation, modification, and deletion of persistent objects 
must
!   be done within the scope of a transaction
!   - transaction is a unit of logic for which an ODMS guarantees atomicity,
!   consistency, isolation, and durability
!   - atomicity means that the transaction either finishes or has no
!   effect at all
!   - consistency means that a transaction takes the ODMS from one
!   internally consistent state to another internally consistent state
!   - there may be time of inconsistency, however isolation guarantees
!   that no other user of the ODMS sees changes made by another
!   transaction until that transaction commits
!   - durability means that the effects of the committed transactions
!   are preserve even in the case of failures of storage media, loss of
!   memory or system crashes
!   - once a transaction commits, the ODMS guarantees that changes made
!   by the transaction are never lost
! 
!     Distributed Transactions
!     ========================
!     - distributed transactions are transactions that span multiple
!     processes and/or multiple databases as described in OMG Object
!     Transaction Service and ISO XA
!     - ODMG does not define an interface for this as it is described in
!     ISO XA and used only by transaction monitors
!     - vendors are not required to support distributed transactions,
!     but if they do they must be XA-compliant
! 
!     Transactions and Processes
!     ==========================
!     - ODMG Object model assumes a linear sequence of transactions
!     executing within a thread of control;i.e., there is one current
!     transaction for a thread, and that transaction is implicit in that
!     thread's operations
!     - if transaction shared by multiple threads in an address space,
!     the transaction isolation must be provided between the threads
!     (i.e., you must protect the transactions yourself via a mutex,
!     etc.)
!     - transactions run against a single logical ODMS, not a single
!     logical ODMS may be implemented as one or more physical persistent
!     stores, possibly distributed on a network
!     -  in the current object model transient objects are not subject
!     to transaction semantics, which means aborting a transaction does
!     not restore the state of the modified transient objects
! 
!     Transaction Operations
!     ======================
!     - TransactionFactory is used to create transactions, it is defined
!     as follows:
! 
!       interface TransactionFactory
!       {
!         // Creates transaction objects
!         Transaction new();
! 
!         // Returns the transaction that is associated with the thread
!         // of control, if there is no current association the current
!         // operation returns nil
!         Transaction current();
!       }
! 
!     - The following operations are defined in the Transaction
!       interface:
! 
!       interface Transaction
!       {
!         // After a transaction object is created, it is initially
!         // closed. An explicit 'begin' operation is required to open a 
!         // transaction. If the transaction is already open, and additional 
calls
!         // to 'begin' operations raise the 'TransactionNotInProgress' 
exception
!         void begin() raises(TransactionNotInProgress),
!                  DatabaseClosed);
! 
!         // Causes all persistent objects created or modified during the
!         // transaction to be written to the ODMS and to become accessible to
!         // other Transaction objects running against that ODMS. All locks held
!         // by the Transaction object are released. Finally, it causes the
!         // Transaction object to complete and become closed. The
!         // TransactionNotInProgress exception is raised if a 'commit' 
operation 
!         // is executed on a closed transaction object
!         void commit() raises(TransactionNotInProgress);
! 
!         // Causes the Transaction object to complete and become closed. The 
ODMS
!         // is returned to the state it was in prior to the beginning of the
!         // transaction. All locks held by the Transaction object are
!         // released. The TransactionNotInProgress exception is raised if an 
!         // abort operation is executed on a closed Transaction object
!         void abort() raises(TransactionNotInProgress);
!     
!         // This operation is equivalent to a commit operation followed by a
!         // begin operation, except that locks held by the Transaction object 
are
!         // not released, Therefore, it causes all modified objects to be
!         // committed to the ODMS, and it retains all locks held by the 
!         //  Transaction object The Transaction object remains open. The 
!         // TransactionNotInProgress exception is raised if a checkpoint
!         // operation  executed on a closed Transaction object
!         void checkpoint() raises(TransactionNotInProgress);
!  
!         // ODMS operations are always executed within the context of a
!         // transaction. Therefore, to execute any operations on persistent 
!         // objects, and active Transaction object must be associated with the 
!         // current thread. The join operation associates the current thread 
with
!         // a Transaction object. If the Transaction object is open, 
persistent 
!         // object operations may be executed; otherwise a 
TransactioNotInProgress
!         // exception is raised
!         void join() raises(TransactionNotInProgress);
! 
!         // If an implementation allows multiple active Transaction objects to
!         // exist, the join and leave operations allow a thread to alternate 
!         // between them. To associate the current thread with another
!         // Transaction object, simply execute a join on the new Transaction
!         // object If necessary, a leave operation is automatically executed to
!         // dissociate  the current thread from its current Transaction
!         // object. Moving form one transaction object to another does not 
commit 
!         // or abort a Transaction object. When the current thread has no 
current
!         // transaction object, the leave operation is ignored.
!         void leave() raises(TransactionNotInProgress);
! 
!         // Checks to see if the transaction object is "open" or begin() has 
been
!         // called.
!         boolean isOpen();
!       };
! 
!     - in order to being a transaction, a Database object must be opened
!     - during the processing of a transaction, any operation executed on a
!     Database object is bound to that transaction
!     - Database object may be bound to any number of transactions
!     - all Database objects, bound to transactions in progress, must remain 
open
!     until those transactions have completed via either a commit or a rollback
!     - if close is called on the Database object prior to the completion of all
!     transactions, the TransactionInPogress exception is raised and the
!     Database object remains open
! 
!   Database Operations
!   ===================
!   - an ODMS may manage one or more logical ODMSs, each of which may be stored 
in
!   one or more physical persistent stores
!   - each logical ODMS is an instance of the type Database, which is supplied 
by
!   the ODMS
!   - Instances of the type Database are created using the DatabaseFactory
!   interface:
! 
!     interface DatabaseFactory
!     {
!       Database new();
!     }
!  
!   Once a Database object is created using new operation, it is manipulated 
using
!   the Database interface:
! 
!     interface Database
!     {
!       exception DatabaseOpen{};
!       exception DatabaseNotFound{};
!       exception ObjectNameNotUnique{};
!       exception ObjectNameNotFound{};
! 
!       // Must be invoked, with an ODMS name as its argument, before any access
!       // can be made to the persistent objects in the ODMS. Object Model 
!       // requires that a single ODMS to be open at a time. Implementations 
may 
!       // extend this capability, including transactions that span multiple
!       // ODMSs, the close operation must be invoked when all a program has 
!       // completed all access to the ODMS. When the ODMS closes, it performs
!       // necessary cleanup operations, and if a transaction is still in
!       // progress, raises the TransactionInProgress exception. Except for  the
!       // open and close operations, all other Database operations must be
!       // executed within the scope of a Transaction. If not, a 
!       // TransactionNotInProgress exception will be raised.
!       void open(in string odms_name) raises(DatabaseNotFound, DatabaseOpen);
!       void close() raises(DatabaseClosed, TransactionNotInProgress);
! 
!       // A name is bound to an object using the bind operation.
!       void bind(in Object an_object, in string name)
!                 raises(DatabaseClosed, ObjectNameNotUnique,
!                        TransactionNotInProgress);
! 
!       // Named objects may be unnamed using the unbind operation.
!       Object unbind(in string name) raises(DatabaseClosed,
!                                            ObjectNameNotFound,
!                                            TransactionNotInProgress);
! 
!       // Finds the identifier of the object with the name supplied as the
!       // argument to the operation. This operation is defined on the Database
!       // type, because the scope of object names is the ODMS. The names of
!       // objects in the ODMS, the names of types in the schema, and the 
extents
!       // of types instantiated in the ODMS are global. They become accessible 
to
!       // a program once it has opened the ODMS. Named objects are convenient
!       // entry points to the ODMS.
!       Object lookup(in string object_name) raises(DatabaseClosed,
!                                                   ObjectNameNotFound,
!                                                   TransactionNotInProgress);
! 
!       // Accesses the root object that defines the schema of the ODMS. The
!       // schema of the ODMS is contained within a single 'Module' meta object.
!       // Meta objects contained within the schema may be located via 
navigation
!       // of the appropriate relationships or by using the resolve operation
!       // with a scoped name as the argument. A scoped name is defined by the
!       // syntax of the ODL and uses double colon (::) delimiters to specify a
!       // search path composed of meta object names that uniquely identify each
!       // meta object by its location within the schema. e.g., 
"Professor::name"
!       // resolves to the Attribute meta object that represents the name of 
class
!       // Professor.
!       ODLMetaObjects::Module schema() raises(DatabaseClosed, 
!                                              TransactionNotInProgress);
!     };
! 
!   - Database type may also support operations designed for ODMS 
administration,
!     e.g., create, delete, move, copy, reorganize, verify, backup,
!     restore. These kinds of operations are not specified in the ODMG spec, as
!     they are considered an implementation consideration outside the scope of 
the
!     Object Model
\ No newline at end of file