09.05.2017 21:34, Jiří Činčura wrote:
> Hi,
>
> I have a weird behavior on FB 3.0.2 32b, confirmed on 3 machines
> (Win2012 R2, Win 10 CU, Win 10 AU). When I execute `isql -x
> database.fdb` the first run is fast. When I execute it then again the
> run is slow, like 5-10x slower. Then again fast and slow, fast, slow,
> fast, slow etc.
>
> The whole repro is here
> http://www.uschovna.cz/zasilka/MAMF5RKT9XYHSAL7-GDI/ . Just run test.bat
> from cmd two times.
>
> Any ideas what's wrong?
This is not trivial story, so prepare for long reading ;)
Start from simplest case, when Firebird server is not running and we deal
with single isql and embedded connect.
Things is going in this order:
1. isql tried to attach to the target database
2. dispatcher ask every known provider (Remote, Engine12, Loopback) to
attach database
3. Remote provider returns isc_unavailable, as expected
4. Embedded provider (Engine12) opens database and return success
5. isql extracts database objects and run few queries.
To show GRANT's, isql query SEC$DB_CREATORS virtual relation.
Engine creates internal attachment to the security database to fill
SEC$DB_CREATORS with data.
6. dispatcher ask every known provider to attach security database
7. Remote provider returns isc_unavailable, as expected
8. Embedded provider opens security database and return success
...
9. isql query SEC$GLOBAL_AUTH_MAPPING virtual relation and engine
creates new internal attachment to the security database to fill
SEC$GLOBAL_AUTH_MAPPING with data.
...
So, when there is no Firebird server running, your case works as expected -
fast on every execution. Note, every execution creates internal attachments
to the security database twice.
When Firebird server is running, things are bit different. Note, usually
Firebird holds cached connection to the common security database.
1. isql tried to attach to the target database (using file path)
2. dispatcher ask every known provider to run attach request
3. Remote provider returns isc_unavailable, as expected
4. Embedded provider opens database and return success
5. isql query SEC$DB_CREATORS virtual relation.
Engine creates internal attachment to the security database to fill
SEC$DB_CREATORS with data.
6. dispatcher ask every known provider to attach security database
7. Remote provider returns isc_unavailable, as expected
8. Embedded provider returns isc_io_error, as security database file
is already opened by the Firebird server in exclusive mode.
9. Loopback provider also fails as there login data is empty and server
denies this attachment requiest
10. Dispatcher returns isc_io_error
... and so on
The most interesting step there is (9) when server denies attachment
request. There is built-in ability to avoid users to attach with wrong
passwords too often - after every 4th sequiential failed login by the
same user within the 8 seconds server delays its answer for the 8 seconds.
Note, we have 2 failed logins at every run of your script. Thus every
second execution is delayed by the server by 8 seconds.
The question i have no good answer for : should code which fills SEC$XXX
tables use any providers other than embedded (Engine12) ?
Regards,
Vlad
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
