Subject | Re: AW: [firebird-support] CS or SS in firebird embedded? |
---|---|
Author | Nando Dessena |
Post date | 2004-09-09T08:40:16Z |
Bud,
about the availability, on Linux, of anything akin to the Windows
embedded engine model I am completely clueless and as confused as
anyone else because of the naming of things and my personal lack of
experience. I can comment about fbembed.dll, though.
usual precaution (which applies to any multithreaded Firebird client
application) that no two threads should ever use the same attachment
at the same time. This rule is often tightened saying that each thread
should have its own connection, which is simpler and works fine.
I hope I have not misunderstood your questions.
Helen,
[I did miss this thread, slowly catching up after vacation]
H> Theoretically, it's not possible, since it uses the IPServer, a kind of
H> "cooked" network protocol where the "wire" is the inter-process
H> communication space that is shared by the client and the server. For Fb 2,
H> the IPServer is being reimplemented to use the virtual local network
H> subsystem, XNET.
Not sure you were still talking about fbembed.dll here, anyway, just
in case... It doesn't use IPServer; it overloads the IPServer syntax
(i.e. just the file name, no host specification) to provide in-process
communication. To recycle your terminology, the "wire" here is the
fine line between a jmp instruction and the called address. :-)
This "protocol" is the fastest way that I know of to access a Firebird
database (engine threads in my own process space), although the
limitation that all requests must come from the same process make it
less widely applicable than it could be.
I once thought this "overloading" would have caused confusion among
users (and it has), and "briefly" argued with Dmitry until he convinced me
that it was technically the right implementation.
H> But wait and see whether Nando Dessena comes back on this one, as he does
H> things with Win Embedded that aren't supposed to be possible...
Huh? I strictly follow the documentation. ;-) I *would like* to do
things that are currently impossible (an embedded server), but since
they are impossible and noone's going to bother making them possible
until Vulcan comes out, I content myself with what's currently
available. Which is [great] BTW. ;-)
Ciao
--
Nando Dessena
mailto:nandod@...
======================================================
I support Firebird, I am a Firebird Foundation member!
Join today at http://www.firebirdsql.org/ff/foundation
======================================================
about the availability, on Linux, of anything akin to the Windows
embedded engine model I am completely clueless and as confused as
anyone else because of the naming of things and my personal lack of
experience. I can comment about fbembed.dll, though.
>>And lastly, about thread-safety: I don't expect 'FB-embedded SS' to beIt's as thread-friendly as fbclient.dll is. You only have to take the
>>thread-safe out of the box, but is it at least thread-friendly? I can find
>>out the answer to this with a lot of testing, but I want to know if anyone is
>>running FB-embedded in a multi-threaded app.
usual precaution (which applies to any multithreaded Firebird client
application) that no two threads should ever use the same attachment
at the same time. This rule is often tightened saying that each thread
should have its own connection, which is simpler and works fine.
I hope I have not misunderstood your questions.
Helen,
[I did miss this thread, slowly catching up after vacation]
H> Theoretically, it's not possible, since it uses the IPServer, a kind of
H> "cooked" network protocol where the "wire" is the inter-process
H> communication space that is shared by the client and the server. For Fb 2,
H> the IPServer is being reimplemented to use the virtual local network
H> subsystem, XNET.
Not sure you were still talking about fbembed.dll here, anyway, just
in case... It doesn't use IPServer; it overloads the IPServer syntax
(i.e. just the file name, no host specification) to provide in-process
communication. To recycle your terminology, the "wire" here is the
fine line between a jmp instruction and the called address. :-)
This "protocol" is the fastest way that I know of to access a Firebird
database (engine threads in my own process space), although the
limitation that all requests must come from the same process make it
less widely applicable than it could be.
I once thought this "overloading" would have caused confusion among
users (and it has), and "briefly" argued with Dmitry until he convinced me
that it was technically the right implementation.
H> But wait and see whether Nando Dessena comes back on this one, as he does
H> things with Win Embedded that aren't supposed to be possible...
Huh? I strictly follow the documentation. ;-) I *would like* to do
things that are currently impossible (an embedded server), but since
they are impossible and noone's going to bother making them possible
until Vulcan comes out, I content myself with what's currently
available. Which is [great] BTW. ;-)
Ciao
--
Nando Dessena
mailto:nandod@...
======================================================
I support Firebird, I am a Firebird Foundation member!
Join today at http://www.firebirdsql.org/ff/foundation
======================================================