Re: Integrity of different transaction of different sessions exchanging data to each other This situation shows one of the uses of the much-maligned share-lock. With
a share-lock (as opposed to no-lock), user B won't be able to retrieve user
A's parent record. You can choose to have user B return a "doesn't exist"
validation error without hanging by using "find .... share-lock no-wait
no-error".
Really roughly, no-lock gives you "read uncomitted", and share-lock gives
you "read committed" isolation. Share-lock fell out of fashion a long time
ago due to the old 4GL style of programming where transactions remained open
while waiting on UI, and no-wait wasn't available before V6 (I think), but
share-lock behaves very much like data accesses on Oracle or SqlServer. |