Here is the scenario: A SQL Anywhere 18.104.22.1685 event makes a connection to a remote server. An EXECUTE IMMEDIATE FORWARD TO statement establishes the actual remote server connection.
Another event detects when the first event has not received control back from the FORWARD TO statement, and this second event runs an EXECUTE IMMEDIATE DROP CONNECTION on the first event's local connection number to stop the waiting.
The DROP CONNECTION statement runs quickly, but it seems the other event's local connection is not actually dropped until after the FORWARD TO returns control. Repeated DROP CONNECTION statements for the same connection number also run quickly... they don't fail, but they don't have any better luck than the first.
In some tests, multiple "the check is in the mail" messages appear in the database console ...
I. 08/24 11:51:32. User "DBA" dropped event connection 1000000033 ("attempt_connection") I. 08/24 11:51:33. User "DBA" dropped event connection 1000000033 ("attempt_connection") I. 08/24 11:51:35. User "DBA" dropped event connection 1000000033 ("attempt_connection")
... for those of you who haven't had your morning coffee yet, it is logically impossible to drop the same connection number more than once :)
Is that expected behavior? ...I suspect it is, just wanted to be sure.
What else (if anything) blocks DROP CONNECTION?
Some insight into the inner workings of DROP CONNECTION would be appreciated... there's more to it than meets the eye :)