KS-SOMED - wiszące sesje oracle - jak sobie z nimi poradzić?

[Michał]

Nie wiem czym jest to spowodowane, ale podejrzewam, że lekarz zamiast wyłączyć KS-SOMED a potem komputer, wyłącza odrazu komputer, co w efekcie daje wiszącą sesję oracle. Wcześniej nie było to aż takim problemem bo część lekarzy z KS-SOMED nie korzystała, ale teraz odkąd obowiązuje eZLA coraz więcej z nich loguje się do programu. Liczbę stanowisk kupiliśmy z zapasem, ale przez takie wiszące sesje coraz częściej zdarza się że ktoś nie może korzystać z programu. Oczywiście wiem, że można ubić wiszące sesje w module Serwis, ale nie zawsze mam możliwość to zrobić, a nie ma niestety nikogo sensownego komu mógłbym nadać do tego uprawnienia.
Na forum znalazłem informację, że wpis

ORDER66=1

w pliku kspl.ini powinien spowodować, że taka sesja będzie automatycznie ubijana. Mój plik kspl.ini w sekcji ALL wygląda tak:

[ALL]
SCIEZKADLL=\\ODPOWIEDNIA_SCIEZKA
ORDER66=1
NO_CHECK_UPDATE=1

ale sesje nie są ubijane.
1. Czy jest jakiś sposób na automatyczne zabicie wiszącej sesji po określonym czasie?
2. Czy można określić ten czas?
3. Po czym program rozpoznaje wiszącą sesję? Czy po dacie i godzinie ostatniej transakcji?
4. Mam odpalone na serwerze np. generowanie raportu MZ-11 albo weryfikację eWUŚ dla wszystkich pacjentów a wiadomo, że jest to czasochłonne i zasobożerne. Staram się takie operacje uruchamiać wieczorem aby wykonywały się w nocy. Czy takie automatyczne ubijanie sesji może zakończyć też moją sesję?

PS. Edukuję użytkowników jak prawidłowo wyłączyć KS-SOMED (nigdy nie myślałem, że będę musiał kogoś szkolić z takiej czynności), ale oni czasami nie są w stanie sobie przypomnieć czy dzień wcześniej zamknęli program przed wyłączeniem komputera czy też nie.

[neelix]

Mi też ORDER66 ostatnio przestał ubijać sesje a wcześniej działało bez zarzutu.

[Profesor Wilczur]

Wersja na Oracle ma zdefiniowane zadanie (job), które wyrzuca nieprawidłowo zakończone sesje.

[MK]

Po pierwsze, sesje Oraclowe nie mają już żadnego bezpośredniego wpływu na licencjonowanie KS-SOMED. Nie mają już od kliku lat. SOMED wykorzystuje wewnętrzna tablicę sesji i to właśnie te sesje, a nie sesje Orcale, widzimy w serwisie i to właśnie te sesje zabijamy w serwisie. Po drugie, napisałem nie maja bezpośredniego wpływu, ale jak najbardziej wpływ pośredni. No bo jeśli już ktoś - ręcznie, bo od kilku lat SOMED tego nie udostępnia - ubije sesję Oracle, to oczywistym jest, że dane połączenie padnie. Na to SOMED wpływu nie ma. I co ważne, wewnętrzna sesja SOMEDowa wówczas zwisa i blokuje licencje. Ale, to po trzecie, jest wspomniany wyżej JOB, który raz na pięć minut sprawdza, czy są sesje SOMED, dla których nie istnieją już sesje Oracle i po prostu je zabija. Zwalniając licencję. Ale tak długo jak długo sesja Oracle istnieje, żaden automat nie wyczyści sesji SOMEDowej. Dlatego, to po czwarte, istnieje w serwisie okienko pozwalające na ubijanie sesji somedowe, pozostawiając oczywiście sesje Oracle, ale jak wspomniałem one licencji nie blokują. Tymi sesjami niech się zajmie serwer lub administrator. Są też narzędzia, to po piąte, pozwalające na automatyczne czyszczenie sesji SOMEDa bez względu na to, czy sesja Oracle istnieje, czy nie istnieje. Narzędzie to wbudowane jest w KS-SOMED i aktywuje je wpis ORDER66 (to, jakby ktoś nie łapał z StarWarsów :-) ). Tylko, tu ważna uwaga, to nie jest cudowne narzędzie, nie jest, bo być nie może. To jest mechanizm pozwalający danemu użytkownikowi zalogować się do swojego systemu bezpośrednio po tym, jak nastąpił upadek. Czyli z jakiś powodów somed upadł. Skoro upadł, to zapewne sesja somedowa pozostała, OK za 5 minut będzie wyczyszczona, ale to za 5 minut. Chociaż, może nawet nie, często po takim upadku nadal sesje Oracle wiszą, więc nawet JOB nie pomoże. Ale przecież lekarz nie będzie czekać! Właśnie temu służy ORDER66. On czyści sesje ale tylko te, które związane są z danym użytkownikiem, a mówiąc dokładnie, z danym numerem stanowiska, żadne inne, tylko te. Zakładamy bowiem, że jeśli dane stanowisko łączy się do bazy, to nie powinno mieć swojej sesji. Jak ma, to pewnie jest to opuszczona sesja. Zwróćmy uwagę, że kolejne instancje maja inny numer stanowiska. I tylko takie sesje mogą być czyszczone. Dlatego ORDER66 nie ma prawa pomóc na opisane w zgłoszeniu przypadki. Nie ma żadnego prawa. Dlaczego tak jest? Ano dlatego, że żaden mechanizm samodzielnie nie jest w stanie ustalić, czy dana sesja jest aktywna, czy nie. Nawet, gdy zwrócilibyśmy uwagę, na czas ostatniego dostępu do bazy danych, to też nic nam nie powie. No bo ktoś może np. przeprowadzać bardzo długa wizytę i operować na skomplikowanym wywiadzie. TYLKO człowiek, analizując inne, dodatkowe informacje (widziałem, że pani Asia wychodziła do domu, byłem w jej pokoju, już jej nie ma, o 23 nikt nie pracuje) może podjąć decyzję, czy dana sesja jest, czy nie jest aktywna. I to zarówno dotyczy sesji Oracle, jak i tych wewnętrznych sesji SOMED.
I tu na marginesie, ORDER66 nie jest domyślnie włączone, bo w nowych instalacjach robiłby mnóstwo szkody. W nowych instalacjach zazwyczaj mamy problemy z numeracjami stanowisk. A to komputery są sklonowane i maja te same opisy, a to inne powody, słowem, bardzo często mamy to nadany ten sam numer stanowiska. SOMED jest przed tym zabezpieczony i podczas odpalania drugiego SOMEDa z tym samym numer pojawi się błąd. No i łatwo to ogarnąć. Pod warunkiem, że nie ma ORDER66. Bo jak pisałem wcześniej, co zrobi ORDER66? Jeśli uzna, że jest już sesja z takim numerem stanowiska, to japo prostu zabije. W efekcie zalogował się Pan Jacek i pracuje. Za chwilę loguje się Pan Staś, ma to samo stanowisko ale jest ORDER66, więc ubija sesję Jacka. Jacek wylatuje. Pod nosem rzucił soczyste słówko ale OK, ponownie się loguje. Co się dzieje? Znów działa ORDER66 i wylatuje Pan Staś.  I tak w kółko. Gdyby nie było ORDER66, to od razu byłoby wiadomo, że mamy dwa te same stanowiska. Dlatego ORDER66 włączamy samodzielnie i wówczas, gdy mamy już stabilną instalację.
Kończąc już ten przydługi i być może nudny wywód, Jedynym rozwiązaniem zgłoszonego problemu, to mądre osoby potrafiące zapanować nad sesjami w module Serwis. Innego rozwiązanie nie ma.

[Michał]

Może i długi ale napewno nie nudny wpis. Co prawda nie rozwiązuje zgłoszonego przeze mnie problemu, ale wydaje mi się że dzięki temu, można obejść problem nawet wykorzystując nietechniczny personel, kiedy ja nie mam możliwości się w danej chwili tym zająć.
Skoro lekarz A dzień wcześniej nie wyłączył prawidłowo SOMEDa i jego sesja somedowa wisi i blokuje licencję, to wystarczy, że jakikolwiek inny użytkownik uruchomi komputer, na którym działał lekarz A i zaloguje się do SOMEDa (tym samym uwali sesję lekarza A) a następnie go zamknie (tym samym prawidłowo zamknie swoją sesję i uwolni licencję). Dzięki temu, lekarz B będzie już mógł się zalogować do SOMED na swoim komputerze, zgadza się?

[MK]

Zgadza się, o ile numeracja stanowisk jest uzależniona tylko od komputera. Niektórzy mają dodatkowo od usera systemu operacyjnego.

[Michał]

Czy jest możliwe, że pomimo tego, że lekarz najpierw wyłączy KS-SOMED a potem komputer, sesja KS-SOMED będzie nadal "wisiała"? Lekarz zarzeka się że po ostatniej rozmowie bardzo się pilnuje i wczoraj na 100% najpierw zamknął program a dopiero potem wyłączył komputer.
Lekarz ten, KS-SOMED używa tylko do wystawiania eZLA. Zanim dzisiaj zabiłem tą sesję, sprawdziłem, że ostatnia transakcja miała miejsce o 16:43, tymczasem komputer został wyłączony ok. 17:43.
Macie jakieś pomysły jak ewentualnie sprawdzić czy lekarz faktycznie wyłączył program przed wyłączeniem komputera?

[Sorn]

order66 u Ciebie nie działa?
W sekcji all mam taki wpis i u mnie wszytko działa. Nikt nie dzwoni z problemem zablokowanego stanowiska.
---------------------
[ALL]
ORDER66=1
---------------------

[Michał]

działa, ale zgodnie z tym co napisał MK. Problem polega na tym, że komputer, na którym sesja zawisła nie jest zbyt często uruchamiany (zazwyczaj tylko na "popołudniówki"). Czyli do czasu kiedy ktoś nie włączy komputera i nie zaloguje się na nim do KS-SOMED wpis nie zadziała. W tym konkretnym przypadku, jeżeli nic bym nie zrobił to sesja wisiałaby do dzisiaj do godz. 16.

[maciejj]

Costatnia transakcja miała miejsce o 16:43, tymczasem komputer został wyłączony ok. 17:43.

sprawdź zarządzanie energią, czy masz włączone "uśpij po". Może lekarz przez ostatnią godzinę nie korzysta już z kompa, lecz ogarnia inne sprawy. Komp po uśpieniu zrywa połączenie z serwerem. Na koniec lekarz wybudza go i zamyka (ignorując komunikat, że utracono połączenie z bazą) i zamyka system. Sesja Somed zostaje.

[Michał]

Wszędzie mam wyłączone usypianie czy hibernowanie. Poza tym w logach systemowych też nie było widać usypiania systemu.

[Michał]

Problem wiszących sesji powtarza się od czasu do czasu, ale dzisiaj pierwszy raz nie mogę winić lekarza.
W piątek (08.02.2019) na serwerze, na którym stoi KS-SOMED (razem z oraclem), do KS-SOMED zalogował się użytkownik (sesja fizyczna, za pomocą myszki i klawiatury podpiętej do serwera ). Popracował i wyłączył KS-SOMED. Dzisiaj (poniedziałek 11.02.2019) znowu komunikat o tym, że liczba licencji już wykorzystana. W module serwis wisi sesja SOMED z piątku. Po zalogowaniu się do KS-SOMED i wylogowaniu (oczywiście sesja fizyczna) sesja SOMED zostaje zwolniona.
W piątek użytkownik prawidłowo zamknął KS-SOMED. Serwer nie był restartowany. Nie wystąpił też żaden błąd KS-SOMED.
Co robić? Jak żyć? Jakieś pomysły?

[Sorn]

W takim przypadku sprawdź jeszcze czy w tle nie wisi kspl.exe na koncie terminalowym. Czy użytkownik na koncie terminalowym, później się wylogował z konta czy tylko zablokował. Jeżeli tylko zablokował to kspl.exe mógł wisieć w tle i blokować sesję (czasami się wieszają przy zamykaniu). Czasami wisi sam osozmok, ale nie wiem czy blokuje też sesję.

[Michał]

dzięki za rady. Wszystko już wcześniej sprawdziłem:
- kspl.exe nie wisiał na koncie terminalowym
- konto tylko zablokowane (nie było wylogowywane)