Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!ucsd!ucbvax!pasteur!icsib1.Berkeley.EDU!hws
From: hws@icsib1.Berkeley.EDU (Heinz Schmidt)
Newsgroups: comp.object
Subject: Re: Parallelism and OOPSs
Message-ID: <18023@pasteur.Berkeley.EDU>
Date: 5 Oct 89 18:48:56 GMT
References: <17791@bellcore.bellcore.com> <477@schaefer.MATH.WISC.EDU> <5553@portia.Stanford.EDU>
Sender: news@pasteur.Berkeley.EDU
Reply-To: hws@icsib1.Berkeley.EDU (Heinz Schmidt)
Organization: International Computer Science Institute, Berkeley
Lines: 61

> Indeed, it seems like everyone has been trying to figure out how to do
> this lately.  For a moment, I'd like to leapfrog the question of
> re-entrancy and ask about the idea of "transactions" in an
> Object-Oriented model.  This could be considered relative to ordinary
> objects, persistent objects, or OO-databases.
> 
...
> Also, transaction processing schemes frequently handle resource
> deadlocks by aborting the the processes involved.  Is this a good idea
> for OO transactions?  Is there a better exception handling mechanism
> available?  Consider it a two-part question: multiple transactions per
> execution thread, and multiple threads of at most one transaction
> each.
> 
> Does anyone have any ideas?  Can you refer me to any papers?

Sometime ago I read about an OO database system called Statice that supports 
similar operations. It is written in FLAVORS (one of the OO Lisp dialects) 
and around FLAVORS (i.e. it stores flavor instances). Statice is implemented
on top of TCP/IP protocols to support multiuser access accress the network.
Transactions are atomic and can be nested, they operate on a cached image of 
DB pages und the cached pages are backep-up only when the toplevel transaction
is successful. Many instances can live on one page and one instance can 
live across many pages. To the application programs the instances appear
to live in the programs' address space. So method execution is usually
inside some transaction. The lowest level atomic transactions compete 
for pages (locking, only one thread can own a page at a time) and deadlocks
in this competition are dynamically detected. When a deadlock is detected
the transaction is aborted (rollback) and within the transaction nesting 
level of your application program you have to handle the exceptional 
condition. For instance you could retry after some delay -- useful if your
methods didn't have sideeffects so far other than on the persistent objects,
which were automatically rolled back to a consistent state -- or, you could
decide to abort this nesting level too, and so on...

Unfortunately I don't recall the reference but I believe there were some 
papers around this theme in the last OOPSLA 88 conf. proceedings.

I think it is a good idea to allow a transaction to operate on many related
objects because data integrity may impose some global consistency constraints 
that you may not be able to maintain in a single operation on a single object
when you have to update the DB.

Obviously the application programmer can save quite some programming effort 
with transactions and rollbacks, in a situation where
(a) there is shared data,
(b) update capabilities on these data are granted non-exclusively, and,
(c) there are global integrity constraints to be maintained whenever data
    can be observed by other application programs on different threats 
    (in other words, at all points between low-level atomic transactions).

 - which objects should be persistent and hence shared by many threads
   running over different hosts in a network?
 - granularity of locking: objects or chunks of objects like above pages?
 - when is locking alone (without rollback) sufficient/more appropriate
   for synchronizing threads running over many objects?
 - are there techniques/tools that could help detect 'out-of-place'
sideeffects, 
   I mean sideeffects on non-persistent objects during transactions?

-- Heinz Schmidt     hws@icsi.berkeley.edu