topic Re: Spin-off: RdB problem in Operating System - OpenVMS

Spin-off: RdB problem

Willem Grooters — Wed, 06 Feb 2008 14:06:28 GMT

This thread http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1200857 offers another functional problem. I didn't want to hijack the thread since that is another matter.
-----
Waiting: 202054F6 _TNA282:....... 5E00A732 00010001 EX
Blocker: 202054F5 _TNA281:....... 550021A6 00010001 PR
-----
My assumption is that if process PID 202054F6 tries to delete a record that has been fetched before by process PID 202054F5.
This seems rather obvious to me.

But what would happen if a third process comes along and would access the same record? It would depend on the transaction setting, propably, but this would be my estimate:

Read only, reserving this table for shared read: SUCCESS
Read only, reserving this table for shared write: SUCCESS
Read write, reserving this table for shared read: SUCCESS
Read write, reserving this table for shared write: WAIT (or FAIL)

and as long as there is a process accessing the record, theprocess trying to delete the record will wait until all processes would commit or rollback their transactions.

It the assumption correct, of what have I misunderstood?

Re: Spin-off: RdB problem

Jean-François Piéronne — Wed, 06 Feb 2008 16:12:36 GMT

A read only can't reserve a table for shared write - write access is not compatible with read only -

Any other read write transaction will wait because on the record already exists a waiting transaction.

It the 3rd transaction was allowed to read the record (setting a PR lock which is compatible with the current granted lock PR) this can lead to a famine where a transaction will never succeeded to update a record.

Re: Spin-off: RdB problem

Willem Grooters — Mon, 25 Feb 2008 14:47:02 GMT

Oops - misfit in perception on my side: It's the requestor's intent that counts, not what the rest of the world could do. Makes sense with EX...
If I undertsood the Black Book correctly, it would mean a PW lock will indeed wait - because incomptability with PR, and not because of EX. But since EX is queued before, it will be granted first. Same result, though. And yes: if another PR comes along, and another, and another, the process requesting EX will have a problem.

WG