Commented by: @dyemanov

This *is* expected, as the embedded server is now (in v2.5) based on the Classic architecture. I believe it is documented in the release notes.
The README must be adjusted though, as it still mentions the prior behavior.

Commented by: Daniel (danyschaer)

Dmitry;

I copied to you what the documentation says. Also, it says:

But you should be aware that you cannot access single
database from a number of the embedded servers
simultaneously, because they have SuperServer architecture
and hence exclusively lock attached databases\.

We developed a whole product for 3 yeard thinking the emebedd engine take care of properly opening database files in exclusive mode, but now we found it is opening in no/exclusive way, and that is being now the source of problems. Users can override the whole archives in the while the embedded server is conected to it.

Is there a way to compel the embedded server to open the database files exclusively?

Dany

Commented by: @dyemanov

Yes I agree the README is incorrect and doesn't reflect the new (changed) behavior. It will be fixed.

There's a way to compile fbembed to have the prior behavior, but it would disable all the new features possible now, so it's not an option for the project. In your case, I'd simply lock the database file at the application level and forget about the issue.

Commented by: Daniel (danyschaer)

Thanks Dmitry, that may be enough for me. Please can you tell me how do I lock the database file at the application level in a way it may not cause problems to Firebird embedded server?.

Thank you very much.

Commented by: @pcisar

Daniel, please direct you further questions to firebird-support list. Tracker is NOT a support forum.

Commented by: Daniel (danyschaer)

Pavel, please ask me this question: is the firebird-support a good place for asking things related to 2.5 beta 2 ??

Commented by: @pcisar

As it's not normally possible to protect open database from accidental deletion, I've decided to reopen the ticket (after consultation with Vlad), but this time as Improvement (current behaviour is correct, so it's not a bug). Vlad suggested to add a DPB flag to open the database in exclusive mode (if possible). However, implementing it for 2.5 is out of question (maybe for some maintenance version at beast).

Commented by: Daniel (danyschaer)

I am glad for this decision. I am fighting with real cases related to this point, and I can show you in private mail (if you give me permission to send you one) that it can be source of good number of troubles. And it is easy to crash with those troubles, in some kind of applications.

Commented by: @pcisar

Daniel, you should understand that opening the database in exclusive mode is not normal for Firebird, it's just implementation artefact. Actually, Firebird initial (and still heavily used) CLASSIC architecture is based on shared access to the database from several server instances. Exclusive access was added to Firebird SUPERSERVER as additional protection from database corruption, because SuperServer architecture introduced by Borland lacks the ability to coordinate access to single database from multiple instances, and simultaneous access would lead to database corruption. As first embedded versions were based on SS architecture, they inherited this trait. But in 2.5 the embedded is based on SuperClassic that doesn't have this constraint, so databases are opened in shared mode. SuperClassic is transitional architecture for FB 3.0, and it's expected that it's future enhanced version would fully replace Classic and SuperServer architectures for good. You should also understand that database opened in exclusive mode would reduce your deployment and configuration options, so if it would get implemented, then as optional feature activated on explicit user request, so you should be prepared to deal with its consequences.

If everything you're concerned about is accidental database deletion / overwrite, then your can easily solve it via OS access privileges.

Commented by: Daniel (danyschaer)

Pavel,

>>>Daniel, you should understand that opening the database in exclusive mode is not normal for Firebird <<<

But we should not forget that it is normal feature in the embedded engine. And we should not forget the embedded option is a key feature in our engine; it is one of the big features making a difference with other engines in the market.

Also, and because of that, people in our Foundation should consider way it is important this feature for programmers.

Programmers that follow the embedded option, normally are programmers developing EASY_TO_DISTRIBUTE - EASY_TO_DEPLOY - EASY_TO_INSTALL products, and if now we have to deal with O.S. access privileges we are doing nothing but adding installation issues, distribution issues, and deployment issues.

EASY_TO_DISTRIBUTE - EASY_TO_DEPLOY - EASY_TO_INSTALL, means copy/paste a folder, for example. It means pasting that folder in a pendrive, and connecting it to another machine for running the application from there.

>>> You should also understand that database opened in exclusive mode would reduce your deployment and configuration options <<<

I can't imagine why more Firebird option will reduce my deployment and configuration options. Moreover, this thread is because we have fewer options now.

>>> If everything you're concerned about is accidental database deletion / overwrite, then your can easily solve it via OS access privileges <<<

Not only; they are thousands of causes why, a programmer will need the option of opening a file in exclusive mode. It is absolutely natural for a programmer to have the option of doing exclusive access to a file, and it is totally normal to use that option. And should think not only about programming problems, you should think about product politics too, for example; O.S. access privileges may be changed buy others, for example, so it is not possible to be sure we are using the file exclusively.

Best regards,

Daniel

Commented by: @pcisar

You are exaggerating the importance of this "feature" for usability and deployment simplicity of embedded server, and in fact, you're hijacking it for the purpose it was never meant to fulfil. If you're after protection of your embedded databases from accidental deletion/override, then use tools for that purpose, because database opened for exclusive access is not what you need. It "protects" the database only when active attachment exists and the sole reason it exists is to protect users from simultaneous attachments from two Firebird server instances that are not able to cooperate, because it would result in immediate database corruption. It was the case of SuperServer only. However, we do agree that this protection (in more generalized form) might be usable even when architectural reasons would be lifted, as two *misconfigured* Firebird instances accessing the same database would lead to the same catastrophic ends.

Commented by: Daniel (danyschaer)

>>> You are exaggerating the importance of this "feature" for usability <<<

We are talking about one very basic low level feature that may be used for lots of things; you don't know how did I used it, so I can't understand how you know I am exaggerating.

>>> If you're after protection of your embedded databases from accidental deletion/override <<<

No, I am not. A customer did a copy of a database file while or application was running. When he tried to use that copy, it found a corruption. He reported the problem, and at that moment we noticed about the news: embedded is not opening the database in exclusive mode; and we said wow, this thing broke our software politics and we didn't be aware of that (FB documentation was wrong about this point, and I also reported that). So my first input was using exactly that real case input as an example (instead of using our main argument: non-exclusive use broke the rules of our software politics).

With much respect, let me say that this is not the first conversation found on FB forums, where members try to determine what is right and what is not right, and I think this is a big error; general purpose software (like a database engine) may be developed taking in mind that the users will think different about what is fine and what is wrong, and much more if the users are programmers. We have to had the necessary "open mind" ability to accept a programmer will do something in some way, just because he want.

In my case, I decided to use exclusive mode for some very important things for my business, and now I can't find a way to do exactly the same things.

Previous embedded engine works in exclusive mode, so the truth is I am not asking here for an improvement, I am asking for backward compatibility need.

I am very sorry if I said something wrong, I do not speak English.

Best regards,

Daniel

Commented by: @pcisar

First, tracker is wrong place to discuss this, so this is my last reply here. You may continue if firebird-devel if you wish.
Second, your point is not valid. You're substituting the implementation artefact that wasn't even supported by all Firebird versions and architectures for real feature. If your user(s) don't know about the well known and documented fact that physical copy of opened database would most likely render the copy corrupted (or redirect the all I/O from master to the copy on some filesystems), then educate them. The ability to access single database from multiple embedded server instances is what many users want, and which wasn't previously possible due to architectural background of embedded version. Opening the database unconditionally in exclusive mode even if there is no reason for it would effectively disable this feature, so it's not going to happen.

You have three options how to proceed from here:

1. Bite the bullet and educate your users or use any other means you see fit to handle this new situation.
2. Don't use v2.5 embedded and use the v2.1 embedded instead that doesn't have this behaviour and wait for "optional opening of database in exclusive mode " feature to be implemented in some future version to upgrade.
3. Make your own version of FB 2.5 embedded with desired behaviour or pay someone to do it for you (it's not a rocket science in this case).

Commented by: @dyemanov

addition to the item (1) above: or just read about the physical database locking (BEGIN BACKUP / END BACKUP or nbackup.exe) and perform file-level copying properly (safe and independent of the engine architecture).