Re: IN PLACE UPDATE of an object type?

From: Michael Schaefers <schaefe3_at_cs.uni-bonn.spam-remove.de>
Date: Fri, 04 Feb 2005 12:57:58 +0100
Message-ID: <ctvo07$q8o$1@f1node01.rhrz.uni-bonn.de>

Frank Piron wrote:
> Am Thu, 03 Feb 2005 12:45:50 +0100 schrieb Michael Schaefers
> <schaefe3_at_cs.uni-bonn.spam-remove.de>:
>

>> Consider the following example TYPE:
>>
>> CREATE TYPE foo AS OBJECT (
>>     state INT,
>>     b BLOB,
>>     
>>     MEMBER FUNCTION difficultFunc RETURN INT,
>>     MEMBER FUNCTION easyFunc RETURN INT
>> );
>>

>

>>
>> !!!BUT: Both foo instances work on the same BLOB and therefore the 
>> instance stored in the database has become inconsistent: the "state" 
>> attribute says "unstructured", but
>> the BLOB data is "structured"!!!
>>

>
> I think you have to implement a mutex protocol to access the BLOB.
> The evtl. updating function difficultFunc has to place a lock
> while working. Locking may be done by dbms_lock() or physical on
> the tables row.
> Both functions easyFunc and difficultFunc have to wait until the
> lock is released.
>

Locking is not the problem. Assume you have a

CREATE TABLE tab (id int, f foo);

and you have a foo instance with id=1 stored in this table. Now you say

SELECT t.f.difficultFunc FROM tab t WHERE id = 1;

This retrieves a _copy_ of the foo instance (with a _copy_ of a BlobLocator, pointing to the _same_ BLOB) and puts it into the difficultFunc as SELF parameter. difficultFunc now reorganizes the BLOB data and stores a different value in "state".

Now the user should execute an UPDATE that overwrites the old foo instance with the altered one. If you don't do that, the foo instance is inconsistent:

When you execute another
SELECT t.f.difficultFunc FROM tab t WHERE id = 1; you retrive a foo instance with the BLOB having been reorganized, but the state value is still the old one :-(

Coming to the point: Is it possible to alter an object in the database without explicitly executing an UPDATE?

Regards,
Michael Received on Fri Feb 04 2005 - 05:57:58 CST