Some developers simulate cursors by using two or more connections from DB-Library™. One connection performs a select and the other connection performs updates or deletes on the same tables. This can 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 the logic 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.
