Some developers simulate cursors by using two or more connections from DB-Library™. One connection performs a select and the other performs updates or deletes on the same tables. This has very high potential to create application deadlocks. For example:
Connection A holds a shared lock on a page. As long as there are rows pending from Adaptive Server, a shared lock is kept on the current page.
Connection B requests an exclusive lock on the same pages and then waits.
The application waits for Connection B to succeed before invoking whatever logic is needed to remove the shared lock. But this never happens.
Since Connection A never requests a lock that is held by Connection B, this is not a server-side deadlock.
