Commented by: @mrotteveel

Why would that need an extra switch? I think that behaviour you describe is the logical one for a shutdown. So make that behaviour implicit to the shutdown functionality.

Commented by: @dyemanov

I'd say this should be the only possible behavior. And as far as I see, it already works this way for -shut -tran. Only -shut -attach waits for the timeout to elapse.

Commented by: @helebor

OK, apparently I didn't express the situation very well for Mark Rotteveel. With the current situation, the requestors wait until the timeout has elapsed; then, if an existing connection is still connected ( in the case of -attach) or an existing transaction is still running (in the case of -tran), the shutdown fails and the waiting requests will succeed. So your assumption of the implicit behaviour is incorrect. The current behaviour is OK for systems that can tolerate a client freeze with no error message. It is not tolerable for browser-based clients, since there is normally no way to warn them ahead and ask them not to log in.

What I am suggesting is an optional -no_wait switch with the underlying mechanism to send a fail error to the waiting requestors immediately the timeout starts. Their application should interpret that message and tell them to try again later.

Dmitry: yes, perhaps you are right about -tran. It is not behaving correctly in 2.5.1 SC, though, but this is probably due to the "trapped user" causing an irresolvable conflict.