Subject | Re: [firebird-support] What is ForcedWrites default? |
---|---|
Author | Olivier Mascia |
Post date | 2004-12-10T16:37:16Z |
Hello Nando,
On Fri, 10 Dec 2004 17:21:50 +0100,
Nando Dessena <nandod@...> wrote:
ND> OM> If you're concerned by robustness, forget the embedded dll.
ND>
ND> this is a bit exaggerated, isn't it? I'd say if you're concerned by
ND> robustness, then write robust programs. :-)
Of course it is exaggerated. Purpose was to shake people minds.
;-)
ND> I don't buy the argument that Firebird is less prone to crashes and
ND> memory overwrites than my own application, just because it is
ND> Firebird. If I decide to host database engine threads in my own
ND> process space I should know what I am doing, of course, but I wouldn't
ND> rule out the option beforehand.
My point is that _if_ your app goes mad, it can get the embedded server
to do dirty things to the database. And the reverse too : if the
firebird embedded server goes mad, it can have adverse effects on your
hosting app. Running both in their individual space, does not make any
of them better. It is just that they can't collaborate to bring chaos.
ND> I'd add: choose a nondefault listening port, configure it to non create
ND> an internal window handle and set the FIREBIRD environment variable
ND> before starting it. That's what I do and it works satisfactorily.
Sure, a snap to configure it that way.
ND> You should look at the compared performaces. I have embedded Firebird
ND> into a server application of mine that could never work with the
ND> TCP/IP throughput Firebird provides, even locally.
Ahhh performance. Sure there is a difference. But if the app can refrain
from doing 10K requests a minute by relying more on the db server, the
difference vanishes (mostly). Also this will be very different with FB 2.
:)
Yours,
--
Olivier Mascia
On Fri, 10 Dec 2004 17:21:50 +0100,
Nando Dessena <nandod@...> wrote:
ND> OM> If you're concerned by robustness, forget the embedded dll.
ND>
ND> this is a bit exaggerated, isn't it? I'd say if you're concerned by
ND> robustness, then write robust programs. :-)
Of course it is exaggerated. Purpose was to shake people minds.
;-)
ND> I don't buy the argument that Firebird is less prone to crashes and
ND> memory overwrites than my own application, just because it is
ND> Firebird. If I decide to host database engine threads in my own
ND> process space I should know what I am doing, of course, but I wouldn't
ND> rule out the option beforehand.
My point is that _if_ your app goes mad, it can get the embedded server
to do dirty things to the database. And the reverse too : if the
firebird embedded server goes mad, it can have adverse effects on your
hosting app. Running both in their individual space, does not make any
of them better. It is just that they can't collaborate to bring chaos.
ND> I'd add: choose a nondefault listening port, configure it to non create
ND> an internal window handle and set the FIREBIRD environment variable
ND> before starting it. That's what I do and it works satisfactorily.
Sure, a snap to configure it that way.
ND> You should look at the compared performaces. I have embedded Firebird
ND> into a server application of mine that could never work with the
ND> TCP/IP throughput Firebird provides, even locally.
Ahhh performance. Sure there is a difference. But if the app can refrain
from doing 10K requests a minute by relying more on the db server, the
difference vanishes (mostly). Also this will be very different with FB 2.
:)
Yours,
--
Olivier Mascia