I have a task to experiment with 2 instances of InterBase XE7 at the same computer.
Install went OK over existing instance gds_db. Don't forget to specify "Multi instance feature" = YES and new port name and number at the second dialog of installer.
Well, first of all, after running 2 instances of InterBase XE7, one at gds_db/3050, another at gds_db/3100, I decided to check do they ever work by connecting to the same database.
You know, SuperServer is one process, that opens database for itself, and none others. So, theoretically (and in previous versions) it locked database file using exclusive access, to avoid file corruption by modifying it with concurrent processes.
Ok, but both instances were able to connect to one DB at the same time! What the crap? Looking into monitoring tables (tmp$) I found that second instance (second connect) show only 1 record in tmp$attachments, while first show 2 records (one of them garbage collector).
Mmm... Then I came to an idea that second instance connected in read-only mode. Tried to update some data, and ...
The insert, update, delete, ddl or authorization statement cannot
be executed because the transaction is inquiry only.
attempted update on read-only database.
Well, I got the idea but did not understand the purpose. Because the instance that connects to the database first will get read-write access, and second - read-only. But there are none options that can set "read-only mode for instance x". So, wins the first one?
For me it seems completely useless and even dangerous in production - unpredictable first connection from the wrong instance can lock DB (read-only) for the main instance. The better way, I think, was to lock DB in exclusive mode. At least, it can show at connect time that someone already opened DB by some another instance.
Install went OK over existing instance gds_db. Don't forget to specify "Multi instance feature" = YES and new port name and number at the second dialog of installer.
Well, first of all, after running 2 instances of InterBase XE7, one at gds_db/3050, another at gds_db/3100, I decided to check do they ever work by connecting to the same database.
You know, SuperServer is one process, that opens database for itself, and none others. So, theoretically (and in previous versions) it locked database file using exclusive access, to avoid file corruption by modifying it with concurrent processes.
Ok, but both instances were able to connect to one DB at the same time! What the crap? Looking into monitoring tables (tmp$) I found that second instance (second connect) show only 1 record in tmp$attachments, while first show 2 records (one of them garbage collector).
Mmm... Then I came to an idea that second instance connected in read-only mode. Tried to update some data, and ...
The insert, update, delete, ddl or authorization statement cannot
be executed because the transaction is inquiry only.
attempted update on read-only database.
Well, I got the idea but did not understand the purpose. Because the instance that connects to the database first will get read-write access, and second - read-only. But there are none options that can set "read-only mode for instance x". So, wins the first one?
For me it seems completely useless and even dangerous in production - unpredictable first connection from the wrong instance can lock DB (read-only) for the main instance. The better way, I think, was to lock DB in exclusive mode. At least, it can show at connect time that someone already opened DB by some another instance.
No comments:
Post a Comment