| Subject | Re: Is Firebird Rock Solid? |
|---|---|
| Author | Adam |
| Post date | 2005-09-30T02:14:11Z |
--- In firebird-support@yahoogroups.com, "dancooperstock"
<dcoops@s...> wrote:
architecture within the same application space as your application.
Normally, the server has a sort of sandbox if you like around it.
Memory faults in a client application might disconnect the
connection, and terminate the client application with all the usual
fireworks.
I imagine if your application has these sorts of fireworks, then the
dll will not be nicely unloaded.
I am not just talking about an unhandled exception, it would have to
be pretty nasty. Others may have some war stories to tell about, so
it isn't meant to be read with the same level of warning about
turning off forced writes. (You could put money on forced writes off
giving you a corruption within a month). Most modern languages would
probably protect you / prevent you from causing the sorts of
fireworks that would cause corruption.
application as yet, but I am investigating its use in an n tier
remote communications module. That sounds a bit more primitive than
it is. I have been testing it quite significantly, accessing it with
multiple threads "simultaneously" (or as simultaneously as you can
get with a single CPU laptop). There have been no stability issues to
date (well except you must realise that the connection components
aren't threadsafe, so you need 1 per thread ;).
Be aware that the security is ignored for this model, so you will
need to put your own level of security if required.
I believe there is also a problem with launching the executable from
a non local drive (like a UNC path) using embedded if you have UDFs.
Adam
<dcoops@s...> wrote:
> You're the 2nd person that suggested that using embedded FirebirdI did say that didn't I. Embedded Firebird launches the SuperServer
> (which is my intention) is a bit more risky. You said in
> particular "you use embedded Firebird and your application does
> something nasty".
>
> Could you be a bit more specific about what my app might do that is
> nasty?
architecture within the same application space as your application.
Normally, the server has a sort of sandbox if you like around it.
Memory faults in a client application might disconnect the
connection, and terminate the client application with all the usual
fireworks.
I imagine if your application has these sorts of fireworks, then the
dll will not be nicely unloaded.
I am not just talking about an unhandled exception, it would have to
be pretty nasty. Others may have some war stories to tell about, so
it isn't meant to be read with the same level of warning about
turning off forced writes. (You could put money on forced writes off
giving you a corruption within a month). Most modern languages would
probably protect you / prevent you from causing the sorts of
fireworks that would cause corruption.
>None that I have experienced. I have not released any embedded
> Are there general problems about using embedded Firebird? The
> intention, of course, is that this will be a single-user app.
>
> Thanks.
application as yet, but I am investigating its use in an n tier
remote communications module. That sounds a bit more primitive than
it is. I have been testing it quite significantly, accessing it with
multiple threads "simultaneously" (or as simultaneously as you can
get with a single CPU laptop). There have been no stability issues to
date (well except you must realise that the connection components
aren't threadsafe, so you need 1 per thread ;).
Be aware that the security is ignored for this model, so you will
need to put your own level of security if required.
I believe there is also a problem with launching the executable from
a non local drive (like a UNC path) using embedded if you have UDFs.
Adam