Find content
Not Telling
Hi Marlon,
OK, so if Timeout -1 in ProIV means "give up instantly on encountering a lock" then that makes sense of the observed behaviour. However, that doesn't sound like a setting that is of very much use in the real world? Also, I notice that ProIV's use of -1 and 0 here seems to be the exact opposite of SQL/Server - which seems to use -1 to mean indefinite wait and 0 to mean no wait (see e.g. https://docs.microso...ql-server-ver15 ).
Given that level of ambiguity, perhaps I should ask here what is really meant by "Table Locking" ? For me, that would normally mean locking entire tables instead of only locking the records (rows) that you read and write. Again, in my experience at least, that's an approach that isn't of much use in the real world.
Regarding "Table Locking" and read uncommitted, I was asking why one would want to set either of them, not suggesting the choices were connected. In most circumstances I would consider both of them unhelpful. Also, I don't see that read uncommitted offers any advantages (only disadvantages) in any database that has multiversioned concurrency control, which I thought SQL/Server had for a long time now?
It does seem dubious that a process is apparently able to lock against itself when then is an 'immediate' timeout but this problem disappears once you wait on locks. I can only imagine something subtle and confusing is going on, such as the actual release of locks happening 'asynchronously' in the background and the process maybe impatiently tripping over locks from its own preceding transaction that haven't quite been released yet (this might be plausible if there is some kind of asynchronous commit being used for performance or as a default). This hypothesis could also be consistent with the tracing slowing everything down causing the problem to be masked.
