Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Message-ID: <3FEEB265.6080204@web.de>
Date: Sun, 28 Dec 2003 11:37:25 +0100
From: Thomas Mahler <thma32@web.de>
Reply-To: thma@apache.org
Organization: Apache Foundation
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821
MIME-Version: 1.0
To: OJB Developers List <ojb-dev@db.apache.org>
Subject: Re: [PFE] locking via database for multi-VM environment
References: <200312201740.33853.on@ukr.net> <200312211441.43543.on@ukr.net>
 <3FE8041B.9080606@web.de> <200312252300.48463.on@ukr.net>
In-Reply-To: <200312252300.48463.on@ukr.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: thma32@web.de

Hi Oleg,

Oleg Nitz wrote:
> On Tuesday 23 December 2003 09:00, Thomas Mahler wrote:
> 
>>I like no 3. ! In fact my whole idea of a LockManager was inspired by
>>the LockServer of the OO database Objectivity. In Objecttivity the
>>Lockserver is a separate server process that works exactly as you
>>describe it in 3)
> 
> Okay, but don't forget about the implicit memory limit. 
> 
Considering todays cheap hardware I don't see a real problem here. If we 
   get tight with RAM we turn on Swapping ;-)

> And what would you say about the variant from my next message?
> I'll repeat it below (with the bug fix applied :)
> -------------------------------------------------------
> one more variant with two sub-variants:
>  
> The record should contain
> - object ID
> - the number write locks: 0 or 1
> - the number of read locks: >=0
> - timestamp
> 

How can we decide if the current transaction holds the write lock on a 
given object if we don't store this information?

> Algorithm 1.
> 
> Read record (database read lock is put at this moment on the record), check if 
> the required lock is permitted, change the record, write (database write lock 
> it put at this moment, if some other database transaction will try to do the 
> same concurrently, one of the transactions will get deadlock exception - at 
> least, in theory :-)
> So everything seems to be okay.
> 
> +: fast, no limits
> -: none :)
> 
> Algorithm 2.
> 
> Set autoCommit=true.
> For write lock:
> UPDATE LOCK_TABLE SET writeLocks=1 
>      WHERE oid=? AND writeLocks=0 AND readLocks=0
> then check the number of updated records, if 0 then the lock failed
> For read lock:
> UPDATE LOCK_TABLE SET readLocks=readLocks+1 WHERE oid=? AND writeLocks=0
> again, check the number of updated records, if 0 then the lock failed
> For different isolation levels we will use different SQL conditions.
> Both for read and write lock the next step:
> if there is a local cached copy of the object then do
> SELECT timestamp FROM LOCK_TABLE WHERE oid=?
> and compare the result to the local timestamp, 
> if changed, then re-read the object.
> 
> 
> +: even faster, no limits
> -: need to use JDBC directly, without intermediate PB layer
> 

Using such "locking" where-clauses works very well typically.
It's quite fast and quite straightforward to implement. I have no 
problems to use native JDBC. (But of course I'd love to see that we 
could use the PB for such a purpose too!)

BUT: Even such a fool-proove approach can fail! Some time ago I used 
such a mechanism to implement a sequence manager for an O/R layer in 
Delphi against a DB2 database.
Everything worked fine when we used the IBM ODBC driver. Then we tried 
to use the Borland native DB2 driver as it was expected to be faster.
It was much faster, but my "locking" where-clauses did not work any more!
As the qualitity of many JDBC drivers is not that high, I expect that 
there could be similar problems with certain JDBC-drivers....

cu,
Thomas

> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org