HP3000-L Archives

June 1999, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
john edwards <[log in to unmask]>
Reply To:
john edwards <[log in to unmask]>
Date:
Mon, 28 Jun 1999 11:12:42 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (47 lines)
I submitted this query to the list last week, but got no replies. Maybe
there was some finger trouble on my part.

Glad to see that someone else has picked up this new Image feature in
rel 6.0.  "Mike Hornsby  Mon 06/28 Thanks HP for automatic deadlock
detection for IMAGE/SQL databases!"  What a pity HP did not invest this
effort 10 years ago!

My questions were:- with the new release 6 of Turbo Image and given
that the options have been enabled correctly:
1) Will the deadlock be trapped/detected in both examples ie single and
multi DB's?
2) What are the processing overheads?
3) Can we now throw away all those locking strategies designed to
prevent deadly embraces. No more fear of a system reboot to release the
locked processes?



Example 1 - One DB
Step 1 - Process 1 DBLOCK on DB1 set1 -unconditional - lock ok
Step 2 - Process 2 DBlock on DB1 set2 -unconditional - lock ok
Step 3 - Process 1 DBlock on DB1 set2 -unconditional -  wait on Process
2
Step 4 - Process 2 Dblock on DB1 set1 -unconditional -  wait on Process
1 - Deadlock

Example 2 - two DBs
Step 1 - process 1 DBlock on DB1 set1 -unconditional - lock ok
Step 2 - process 2 DBlock on DB2 set1 -unconditional - lock ok
Step 3 - process 1 DBlock on DB2 set1 -unconditional - wait on Process
2
Step 4 - process 2 DBlock on DB1 set1 -unconditional - wait on Process
1 - deadlock



Thanks
John




_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

ATOM RSS1 RSS2