Logging out users prior to performing an administrative task is such a common requirement that I give it barely any thought.  This complacency bit me recently, and – since I suspect that I’m not alone – I want to share a simple observation about the MaxL operations involved.

There are typically two steps to kicking users off an application.  My problem stems from the “logical” order in which I think of them:

• “Get out!”
• “And stay out!”

In MaxL this is expressed with the following commands:

alter system logout session on application "MyApp" force;
alter application "MyApp" disable connects;

The problem arises because “logout session” runs for a non-negligible amount of time, and a user may be able to log in during that time. The subsequent “disable connects” succeeds, but does not have any impact on an existing session. The net result is that sessions continue to exist on “MyApp” (which then block other operations) despite running these two commands.

This scenario is definitely not purely hypothetical; It happened to me, and I also found it easy to replicate with a MaxL session and Smart View.

The simple solution is to “lock the door” first, before (presumably) defenestrating the users. In other words, the “disable connects” should precede the “logout session”:

alter application "MyApp" disable connects;
alter system logout session on application "MyApp" force;

In my case, getting caught out caused an error on a production system. You may well already do this, and it’s an easy fix. The more important reminder is that even basic scripts deserve thought, and “I’ve always done it this way” is a terrible argument.