Subject | Re: Question from discussion on OSNews |
---|---|
Author | Alexander V.Nevsky |
Post date | 2004-02-09T19:33:32Z |
--- In firebird-support@yahoogroups.com, "Bernard Devlin"
<knowledgeworks@k...> wrote:
non-exclisive mode. DDL statement affect system tables at time of
execution, but system tables are only interface to internal machinery,
which is changed on Commit. In many cases FB protects itself waiting
for lock resolution on metadata changes, in others generates
exceptions of kind "... in use". SP changes becomes visible to
connections other than connection which made them after re-connect
only, before re-connect they use old version even if changes are
commited. Usage of changed and not commited objects even in the same
transaction which changed them is'nt in general safe.
Best regards,
Alexander.
<knowledgeworks@k...> wrote:
> There's been a little discussion about Firebird over on the OSNewsaltered
> forum, and this question came up:
>
> >>
> I have a question for the Firebird users out there: How thorough is
> its MVCC support? For example, in PostgreSQL, I can start a
> transaction and issue ALTER TABLE and DROP TABLE commands. Only that
> transaction will see those changes - other transactions continue
> normally. I know MySQL can't do this. Can Firebird?
> <<
>
> I started to look into this in order to provide an answer to this
> question, but I'm not really sure how to interpret what I am seeing.
> I have two sessions in isql:
> - set the transaction isolation level of SessionA to 'snapshot';
> - set the autoddl of SessionB off and alter the table definition in
> SessionB;
> - SessionA hangs waiting for a commit or rollback from SessionB;
> - Once that commit has taken place, then sessionA can see the
> table.Bernard, FB in general is'nt adopted to change metadata in
>
> Is this correct behaviour? Is there anything else I can point out
> with regard to this question?
non-exclisive mode. DDL statement affect system tables at time of
execution, but system tables are only interface to internal machinery,
which is changed on Commit. In many cases FB protects itself waiting
for lock resolution on metadata changes, in others generates
exceptions of kind "... in use". SP changes becomes visible to
connections other than connection which made them after re-connect
only, before re-connect they use old version even if changes are
commited. Usage of changed and not commited objects even in the same
transaction which changed them is'nt in general safe.
Best regards,
Alexander.