Subject Re: embedded twice
Author Adam
--- In firebird-support@yahoogroups.com, Jan Bakuwel <jan.bakuwel@...>
wrote:
>
> Hoi Boguslaw,
>
> > I'm still unsure. Does it allow that *both* applications can write to
> > the same database in the same time supposing that exactly the same
> > fbembed.dll is loaded by both (that's why I asked about two programs
> > from the same directory) ?
>
> There is no need to be unsure. You cannot use one db simultaneously
with
> the embedded server. Full stop. Only 1 (as in one) user of the db is
> possible at any time.

At the risk of adding some confusion, I will clarify.

When you use the embedded dll, you are loading the superserver engine
into the process space of the application that launched it.

If you use the embedded dll in two applications, then you get two
instances of the Superserver engine, one in each process space.

You can not have two different Firebird engines playing around with
the same file. Hopefully it won't let you, but if it does you could
bet on corruption occuring.

So only a single process can connect to a database through the
embedded server.

However it is possible to make multiple connections to the database
from the single application. For example if your application is
multi-threaded, you are able to make a different connection from each
thread.

For the original question, can one be readonly, the other not. No. The
database file can be put in readonly mode through gfix which can be
used for distribution of CDs with databases etc. If it was in readonly
mode, then it probably wouldn't corrupt the database but I doubt it
would let you do it.

But if the database needs one writable connection then it is not
readonly. In this case, the readonly transaction still does some
writing to the transaction inventory page. Otherwise, how would the
garbage collection know that your 'read only' transaction was
interested in a record version. I do not know if the read-only
transaction would also do garbage collection too but I don't see why
it wouldn't be involved in the co-operative gc.

So in your case, you will need to use one of the other engines, or
create your own data access layer that acts as a proxy.

Adam