Linux

You might consider a stateful local intermediate demon that takes your logout loggin request and stores it, then fulfills it as soon as the database is available. Of course, this does not give immediate status, but does ensure accurate history, so it is a matter of priorities.

I still suspect there is a log of connections made and lost in most RDBMS that makes your table redundant. It might be a flat file you could frequently sync your table to. Then, it is accurate even if the client machine is crashed or power of net drops suddenly. Not only is this sufficient, it might be necessary!

the script don't have a continuous connection to the DB but make connection only when events occur (login/logout)

I have a flat file for debugging but i think that if the script run when system going down can't recognize the user logout...that's why want to simple make a delay between logout and shutdown...

So, are users that log in tcp/ip connected to anything, or just holding recent cookies in a browser?

sorry don't understand this point...

Sometimes stuff is hard to do because everyone else discovered you should not do it that way!

I am just trying to get a handle on what you are monitoring with your sql rows. The monitoring of clients is better done on the server, as clients can have problems saying "I am broke, gone" because they are broke or gone. Servers can tell if connections are broken, but web apps do not need continuous connection. Even tcp connections are not that good an indication, with all the keep-alive faking on the networks to reduce congestion. An application level keep-alive heartbeat is sometimes necessary for real monitoring.

The purpose of monitoring may be status (is everyone on?) or history (has everyone been on 8 hours 5 days this week?, How many are on, on average>).

This is a bit like removing the appendix through the left nostril -- limited perception or available action!