Before I get too many people telling me that my
examples of an IMAGE deadlock are wrong - here is a correction:

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

There I hope I got the examples right this time!

The question remains - 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?

Thanks
John

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

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