hi all
Я столкнулся с чем-то неведомым и таинственно-опасным :-)
В узких кругах широко известно, что база security3.fdb может висеть открытой после того, как закроется последний дисконнект, дабы следующий коннект выполнялся быстрее (и это зовётся linger). Дока утверждает, что такое происходит (и имеет смысл) только для арх-ры Super
Server .
А теперь посмотрим, что там будет в арх-ре Super
CLASSIC .
Вот конфиг:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
C:\MIX\firebird\fb30sc>findstr /r /c:"^[^#;]" firebird.conf | sort
AuthClient = Legacy_Auth,Srp,Win_Sspi
AuthServer = Legacy_Auth,Srp
DefaultDbCachePages = 128
FileSystemCacheThreshold = 65536K
LockHashSlots = 22111
MaxUserTraceLogSize = 99999
RemoteServicePort = 3330
SharedCache = false
SharedDatabase = true
TempDirectories = c:\temp
UserManager = Legacy_UserManager,Srp
WireCrypt = Disabled
Далее, скачиваем:
1) утилиту
mtee.exe для дублирования вывода консоли в файл, с возможностью приклеивания к сообщениям таймштампов;
2) утилиту Руссиновича из SysInternals, которая показывает, какие файлы открыты. Она назвается
Handle.exe .
И создаем вот такой батничек (я ему задал имя = `h4sec3.bat`):
1.
2.
3.
4.
5.
@echo off
del handle.log 2>nul
:m1
Handle.exe | findstr /i /c:"security3.fdb" | mtee /t /+ handle.log
ping -n 2 127.0.0.1>nul
goto m1
Делаем рестарт FB 3.0 SC. Запускаем батник - его вывод будет пока что пустым.
Затем открываем второе cmd-окошко и вводим там:
echo select current_timestamp from rdb$database; | C:\MIX\firebird\fb30sc\isql localhost/3330:e30
В окне с батником немедленно появятся мессаги:
1.
2.
3.
21:37:47.265 1C4: File (RW-) C:\MIX\firebird\fb30sc\security3.fdb
21:37:48.390 1C4: File (RW-) C:\MIX\firebird\fb30sc\security3.fdb
21:37:49.530 1C4: File (RW-) C:\MIX\firebird\fb30sc\security3.fdb
. . .
-- которые для первого запуска ISQL будут лезть примерно 10 сек:
1.
2.
3.
. . .
21:37:54.062 1C4: File (RW-) C:\MIX\firebird\fb30sc\security3.fdb
21:37:55.202 1C4: File (RW-) C:\MIX\firebird\fb30sc\security3.fdb
21:37:56.374 1C4: File (RW-) C:\MIX\firebird\fb30sc\security3.fdb
Закрываем батник, копируем протокол 'handle.log' в куда-нибудь.
Затем повторяем опять:
* запускаем батник
* запускаем
echo select current_timestamp from rdb$database; | C:\MIX\firebird\fb30sc\isql localhost/3330:e30
Смотрим в окно батника: вроде бы опять файл sec3.fdb был открыт около 10 сек:
1.
2.
3.
4.
5.
6.
7.
21:38:29.171 1D4: File (RW-) C:\MIX\firebird\fb30sc\security3.fdb
21:38:30.296 1D4: File (RW-) C:\MIX\firebird\fb30sc\security3.fdb
21:38:31.437 1D4: File (RW-) C:\MIX\firebird\fb30sc\security3.fdb
21:38:32.562 1D4: File (RW-) C:\MIX\firebird\fb30sc\security3.fdb
21:38:33.687 1D4: File (RW-) C:\MIX\firebird\fb30sc\security3.fdb
21:38:34.843 1D4: File (RW-) C:\MIX\firebird\fb30sc\security3.fdb
21:38:36.015 1D4: File (RW-) C:\MIX\firebird\fb30sc\security3.fdb
21:38:37.171 1D4: File (RW-) C:\MIX\firebird\fb30sc\security3.fdb
А теперь, почтеннейшая публика, внимание!
Повторяем всё еще раз, т.е. делаем ТРЕТИЙ запуск батника и "echo ... | isql ...".
И любуемся в окно батника:
1.
2.
3.
4.
5.
6.
7.
21:38:57.515 1DC: File (RW-) C:\MIX\firebird\fb30sc\security3.fdb
21:38:58.655 1DC: File (RW-) C:\MIX\firebird\fb30sc\security3.fdb
21:38:59.780 1DC: File (RW-) C:\MIX\firebird\fb30sc\security3.fdb
. . .
21:39:53.499 1DC: File (RW-) C:\MIX\firebird\fb30sc\security3.fdb
21:39:54.655 1DC: File (RW-) C:\MIX\firebird\fb30sc\security3.fdb
21:39:55.827 1DC: File (RW-) C:\MIX\firebird\fb30sc\security3.fdb
FB, работающий в режиме Super
CLASSIC , держал открытым файл security3.fdb примерно 57 секунд!
Наблюдение за картинкой в ProcessExplorer'e (см аттач) показало, что:
1) когда к ФБ выполняется коннект, то он открывает (помимо прочего) вот такие три файлика:
1.
2.
C:\Documents and Settings\All Users\Application Data\firebird\fb_trace_******
C:\Documents and Settings\All Users\Application Data\firebird\fb_user_mapping
C:\Documents and Settings\All Users\Application Data\firebird\fb12_trace
2) когда коннект закрывается, то несмотря на то, что после <N> секунд закрывается также и sec3.fdb, эти файлы продолжают держаться открытыми еще какой-то отрезок времени <T>;
3) если
третье и последующие подключения к базе (с немедленным дисконнектом) происходят после <N>, то до истечения <T>, то sec3.fdb будет удерживаться открытым уже не ~9...10 секунд, а почти минуту.
Обращаю особое внимание: это происходит на Super
CLASSIC 'e.
Это было сделано намеренно или сиё есть "какая-то нелепая случайность" ?
