Deadlocks and SHOW-ITEM-LOCKS - jBASE 4.1

[Pawel (privately)]

Hello,

1. Deadlocks
Are they somehow resolved / controlled by jBASE 4.1? I think they are :)
which surprised me a lot.

I have created 2 simple programs in a following way:
Program A: READU RECORDITEM1; SLEEP 1000; READU RECORDITEM2
Program B: READU RECORDITEM2; SLEEP 1000; READU RECORDITEM1
and run them both in background.

I was positively surprised that after 3-5 seconds my second program went
into debbuger with jBASE "DEADLOCK" error.

Questions:
a) Is it possible to force program to logoff on deadlock situation
(avoid going into debugger) or to inform gracefully about situation and
handle it?
b) Are deadlocks detected disregarding from transaction context? (I am
talking about locks automatically taken when transaction is open)

2. SHOW-ITEM-LOCKS
How does this command work? Can I somehow programatically access locks
table? PROC file does not seem to keep any infomation about locks taken
by processes.

I would need something similar to SHOW-ITEM-LOCKS which displays locks
disregarding from selected locking mechanism.

Thank you very much for your time and good night.

Kind regards
Pawel

----------------------------------------------------
Życie w "Atramentowym Świecie" stanie się nie do zniesienia...
Przeczytaj! http://klik.wp.pl/?adr=http%3A%2F%2Fcorto.www.wp.pl%2Fas%2Fatrament.html&sid=513

[Jim Idle]

On Fri, 2008-10-10 at 23:52 +0200, Pawel (privately) wrote:

Hello,

1. Deadlocks
Are they somehow resolved / controlled by jBASE 4.1? I think they are :) 
which surprised me a lot.

Depends on what locking mechanism you use.

I have created 2 simple programs in a following way:
Program A: READU RECORDITEM1; SLEEP 1000; READU RECORDITEM2
Program B: READU RECORDITEM2; SLEEP 1000; READU RECORDITEM1
and run them both in background.

I was positively surprised that after 3-5 seconds my second program went 
into debbuger with jBASE "DEADLOCK" error.

Questions:
a) Is it possible to force program to logoff on deadlock situation 
(avoid going into debugger) or to inform gracefully about situation and 
handle it?

Programs can be told that they are not allowed to enter the debugger and perform a number of things instead of that.

Try the ON ERROR clause (which should be applied to all file IO statements of course but nobody ever does), and inspecting SYSTEM(0) or the SETTING clause.

There not really anything a DBMS can do about resolving deadlocks. Some systems allow you to tell it to abort the transaction that involves the most writes or the least reads and so on, but at the end of the day, on a system like jBASE a deadlock is a hard coded application error, whereas on systems that use other internal structures it can happen even to well behaved applications, which are expected to recover and retry their transaction/write/read.

b) Are deadlocks detected disregarding from transaction context? (I am 
talking about locks automatically taken when transaction is open)

Yes. If you are locking in different orders through different code paths, then the application is in error. The fact that locks are not released until the transaction is ended sometimes exposes these faults more harshly when a program is converted from non-transactional to transactional, but you can't deadlock if your application logic is correct.

2. SHOW-ITEM-LOCKS
How does this command work? Can I somehow programatically access locks 
table? PROC file does not seem to keep any infomation about locks taken 
by processes.

See here:

http://www.jbase.com/knowledgebase/manuals/3.0/30manpages/man/uti2_SHOWITEMLOCKS.htm

Then follow the link to:

http://www.jbase.com/knowledgebase/manuals/3.0/30manpages/man/adv32_CustomizingUtils.htm

Jim