W zmiennych programu są zdefiniowane dwie wartości parametryczne określające dopuszczalne czasy nieaktywności, a decydujące o uznaniu rekordu stacji za przeterminowany i nadający się do automatycznego usunięcia. Są to: Log_Time_Over, określający przedział czasu od zalogowania (przykładowo 20 godz.) oraz Action_Time_Over określający czas braku aktywności od ostatniej zmiany planszy (przykładowo 5 godz.). Pierwszy z tych parametrów - Log_Time_Over - można wykorzystać bardziej restrykcyjnie, kwalifikując rekord stacji jako osierocony na podstawie czasu, jaki upłynął od rozpoczęcia pracy, nie zważając na bieżącą aktywność użytkownika. Parametr ten może okazać się przydatny także w sytuacji przyjętej tu metodologii działania funkcji LOGIN, gdzie nie jest od razu wykonywany wpis do kolumny Last_Action_Time, pozostawiając tam wartość NULL.

Gdy wystąpi nie kontrolowane przerwanie pracy stacji roboczej przed pierwszym wykonaniem funkcji ACTIVITY i bez późniejszego restartowania tej stacji (co jest oczywiście bardzo pechowym zbiegiem okoliczności, ale zawsze trzeba mieć wzgląd na wszechobecne prawa Murphy'ego), nie wiadomo jak długo rekord taki może tkwić jako osierocony.

Odłączyć, nie odłączyć...

Istnieje dosyć duża rozpiętość możliwości oceny, kiedy rekord stacji roboczej należy uznać za przeterminowany. W przytoczonej tu przykładowej implementacji funkcja o nazwie REMOVE_OLD wywoływana z wnętrza funkcji ACTIVITY, czyli dość często, usuwa osierocone rekordy stacji roboczych. Do usunięcia są kwalifikowane wszystkie wiersze tabeli TM, w których czas od ostatniej aktywności (Last_Action_Time) przekroczył limit określony w parametrze o nazwie Action_Time_Over lub od momentu zalogowania (Login_Time) upłynęło więcej czasu, niż określono w parametrze Log_Time_Over. Są także usuwane wiersze, gdzie różnica czasu od momentu zalogowania do chwili obecnej jest większa niż 2 min, a w kolumnie określającej aktywność (Last_Action_Time) ciągle tkwi wartość NULL, co oznacza, że stacja po założeniu wpisu w tabeli nie podjęła aktywności.

Funkcja REMOVE_OLD jest jedną z ważniejszych, ponieważ ostatecznie decyduje o tym "kto zostaje, a kto wylatuje". Z racji tego, że wszystkie opisane tu działania są przekazywane na serwer SQL, stosowane funkcje daty/czasu DATEDIFF i GETDATE operują na czasie dotyczącym serwera, a nie stacji roboczej, podczas gdy wartości Last_Action_Time i Login_Time są pobierane z czasu systemowego obowiązującego na stacji. Dlatego tak ważna jest synchronizacja czasowa stacji klienckich z serwerem. Przy jej braku może się okazać, że procedury usuwające rekordy osierocone wskutek złej interpretacji czasu bezpodstawnie usuwają wpisy użytkowników aktywnych.

Function REMOVE_OLD()

strSQL = "delete TM where datediff(n, Login_Time, GETDATE()) >" & Log_Time_Over & " or datediff(n, Last_Action_Time, GETDATE()) >" & Action_Time_Over & " or datediff(n, Login_Time, GETDATE())>2 and Last_Action_Time is null"

WYKONAJ_SQL (strSQL)

End Function

Bez trudu można sobie wyobrazić, że wartości daty i czasu używane w opisanych tu procedurach, a dotyczące czasu zalogowania i śledzenia aktywności, wcale nie muszą pochodzić ze stacji. Za każdym razem, gdy jest uaktualniany wpis Last_Action_Time lub Login_Time, ich wartości mogą być ustalane na bieżąco przy użyciu funkcji GETDATE serwera. Z drugiej jednak strony, powoduje to zbędne obciążanie serwera czynnościami nie wnoszącymi do rozwiązania niczego nowego.

Prawidłowe zakończenie pracy aplikacji z serwerem powinno wyrejestrować użytkownika, usuwając jego wpis z tabeli TM za pomocą funkcji REMOVE_OWNER.

<hr size="1" noshade>Opisane w tym artykule procedury są jedynie pewnym przykładem zastosowań, które w zależności od potrzeb mogą przybierać różne formy. Istotny wpływ na powodzenie takiego rozwiązania mają: przyjęty sposób identyfikacji obiektów oraz poprawne zdefiniowanie wartości uznawanych za krytyczne, jakimi z pewnością są stałe czasowe decydujące o tym jak długo będą przechowywane wpisy w tabeli monitorowania. Utrzymując taką strukturę informacyjną, jednolicie traktowaną przez współpracujące aplikacje, jest możliwe użycie jej do wielu celów. Implementację konkretnych przypadków z wykorzystaniem analogii do zaprezentowanych tu mechanizmów, w tym np. do programowego kontrolowania blokad zasobów, pozostawiam inwencji programistów.