Subject | Re: [firebird-support] Re: Hibernate, alter table and single user |
---|---|
Author | Helen Borrie |
Post date | 2005-03-03T03:12:23Z |
At 08:37 PM 2/03/2005 +0000, you wrote:
other query in another transaction, then the transaction in which you want
to do the metadata changes doesn't have exclusive access.
Another scenario that commonly causes novices to puzzle is that they are
running some kind of SQL viewer and find that interactive or scripted
changes requested through ISQL fail due to "Object in Use".
So - for all purposes - exclusive access means that one instance of sysdba
or owner or (on Linux, root) -- but not "one of each" -- is logged in to a
shutdown database and is operating inside one and only one transaction.
Be aware that the engine won't *prevent* multiple logins by root and/or
sysdba, and won't prevent sysdba or root from logging in while the database
is shut down and db owner thinks it has exclusive access.
In an environment where user access is carelessly distributed around the
system, the only way to ensure that exclusive access really is exclusive is
to do drastic stuff like stopping the server and renaming the database file
(or the first database file, in the case of a multi-file db). IOW, the
engine is not idiot-proof.
./hb
>I guess my question, then, is...as shipped, does sysdba/masterkeyNo
>have exclusive access,
>or does it take the gfix -shut to make it so?Yes
>To put it another way, I've only created a database asYes. If you are running some admin client that is showing metadata or some
>sysdba/masterkey, I've created no users, and all I've done is to run
>the Hibernate sample program, so is there any reason I would NOT
>have exclusive access at this point?
other query in another transaction, then the transaction in which you want
to do the metadata changes doesn't have exclusive access.
Another scenario that commonly causes novices to puzzle is that they are
running some kind of SQL viewer and find that interactive or scripted
changes requested through ISQL fail due to "Object in Use".
So - for all purposes - exclusive access means that one instance of sysdba
or owner or (on Linux, root) -- but not "one of each" -- is logged in to a
shutdown database and is operating inside one and only one transaction.
Be aware that the engine won't *prevent* multiple logins by root and/or
sysdba, and won't prevent sysdba or root from logging in while the database
is shut down and db owner thinks it has exclusive access.
In an environment where user access is carelessly distributed around the
system, the only way to ensure that exclusive access really is exclusive is
to do drastic stuff like stopping the server and renaming the database file
(or the first database file, in the case of a multi-file db). IOW, the
engine is not idiot-proof.
./hb