NexusDB

If you start a transaction, read from a table... and then keep the transaction open for a long time. Getting shared lock exceptions from other clients trying to modify this locked table is "as expected".

Taking a look at an example exception:

"NexusDB: tbAppel: Lock time out.
The requested exclusive transaction lock for table "APPELS" could not be
granted due to a conflicting shared transaction lock.

The conflict occurred with the following session:

Connected since : 10/06/2005 09:24:59
anonymous User
Connected from : 10.10.12.50:3550[2809/10249]"

What is happening here is quite simple:

You tried to modify tbAppel. No matter if that happens during in explicit transaction or the implicit transaction that is started inside Post if you didn't have an explicit transaction, you need to acquire an exclusive (= read/write) transaction lock on this table. It was not possible to acquire this lock instantly, so the server started to wait for any conflicting locks to be removed one way or another. After waiting for <timeout> msecs the server returned with a "Lock time out" error, informing you that another session currently is holding a shared transaction lock on that table. The other session connected to the server at 10/06/2005 09:24:59. No username was specified. The connection originated from the computer with the IP 10.10.12.50.

The only reason why that other session would be holding a shared transaction lock for that time is that the other session called StartTransaction, then read from the table "APPELS" and didn't either commit or rollback this transaction inside the time that your session had been waiting, trying to acquire the exclusive lock required to modify that table.

There is no bug here. All that you are seeing is expected behaviour given the way your software is written. You have 3 options here:

• make sure the session doesn't keep a transaction open for that long. Make sure all explicit transactions are wrapped into a try finally block that either commits or rollback them. Mostly these error occur though if a user is putting a record into edit mode and then e.g. goes out for lunch. (Never have a transaction who's lifetime depends on user interaction).
• if there is no important dependency between the tables that the session is modifying inside the transaction and the information it reads from the "APPELS" table that requires enforcement of transaction isolation: create 2 different TnxDatabase instances, both using the aliasname/aliaspath, attach the tables that should be part of the transaction to one of them, attach the tables that you use for reading information which doesn't require enforcing of transaction isolation to the 2nd.
• implement proper exception handing in all your clients to automatically retry operations that timed out and give the user visual feedback that a lock conflict exist with another session and where that other session originates while you keep automatically retrying the operation until it succeeds or the user aborts the operation.