So, it's set for cautious locking in the main. (Some of the entities in the model are views, and are set to No Updates.)
Mss driver config is currently
USYS$MSS_PARAMS ri: uniface, procs: off, ids:quoted, hold statements:on,mlw:300, locktime:300,gran:row, stmtcache:off,iso:ru,os:96, sql92npw=on, mars:on, step:0
BUt we have been using.
USYS$MSS_PARAMS ri: uniface, procs: off, ids:quoted, hold statements:on,mlw:infinite, locktime:infinite,gran:row, stmtcache:off,iso:ru,os:96, sql92npw=on, mars:on, step:0
The system is entirely client server, so (almost) all updates are done by the userver processes, and therefore lock timeouts cannot be universally fed back to the user without a lot of coding, We'd prefer not to have locks time out, but just to wait and get on with the job when they can.
The data is all in one database, using one path ($DEF), some specific services are started "TRANSACTION=TRUE", but they are small, single record updates, so they can't cause deadlocks.
I have started a SQL server deadlock trace event log I don't entirely understand, but it shows me one from today, which (it appears) is the update of an indexed view in the database. We use indexed views because uniface's handling of (most) views appears to be slow ( the filter criteria are applied after the view is implemented, so SQL works out 1000's of answers to return one.
However, this is not the only place in the system the deadlocks occur, so it's probable other things also cause it.
If I can spot that it's occurred somehow, I can build that into my important transactions to ensure uniface rolls back and (potentially) retries the transaction when not all of it has been properly updated, but How do I spot them?