Subject | RE: [IBO] AV when switching to another app |
---|---|
Author | Helen Borrie |
Post date | 2005-05-10T08:03:09Z |
At 05:03 PM 10/05/2005 +1000, you wrote:
meticulously separate each entire database session from all of the others -
including the master session.
To be more exact about what I'm referring to as "IPServer" (which Nando
repeatedly says is not involved), this is *not* the plug-and-play IPServer
product that emerged lately in the .NET environment. It is (was) a hack
developed by Borland back at (AFAIR) IB 4.0, long before asp or .NET had
ever been thought of, to simulate the "direct local connect" that was used
by their iblocal DLL. IBLocal was a library that shipped with their Delphi
1 and C++ 4.5 products. This was a single-instance server that loaded from
the IDE. Applications literally did connect directly and you got one client
connection. Multi-threading Delphi 1 apps was a non-issue.
When they began distributing Superserver, they changed this "Windows local
connect" mechanism to be an emulation layer that could be accommodated by
the client layer as though it were a network protocol. They referred to it
as "IPServer" ("Inter-Process server", nothing to do with Internet protocol
) because it manages the database engine and the client layer in the same
inter-process communication space. That's the reason shared sessions are
not thread-safe.
As to multiple threaded sessions in Embedded being "perfectly safe", I'd
certainly be interested to hear actual load-testing evidence of that,
instead of hyberbolic claims and hearsay. All I've found so far, under lab
conditions, is that the server and the clients will crash under fairly
minor thread-load, i.e <10 threads performing trivial operations on my
workhorse Intranet server, a 455 MHz PII Celeron with 384Mb RAM. The same
and greater loads on the same gear under Classic or Superserver, connecting
via localhost, don't suffer from this problem. What's more, there is no
difference in performance, at least on this fairly low-spec setup.
I continue to regard v.1.5 Embedded as somewhat experimental and, at best,
a staging-point on the road to the more robust XNET implementation that
Dmitry planned all along. I don't think it is overly responsible of people
to make the kind of claims that Nando does regarding the Fb 1.5
implementation, without citing some numbers.
Helen
>what's not thread safe Helen? embedded is quite safeAs Nando pointed out three times, it's thread-safe as long as you
meticulously separate each entire database session from all of the others -
including the master session.
To be more exact about what I'm referring to as "IPServer" (which Nando
repeatedly says is not involved), this is *not* the plug-and-play IPServer
product that emerged lately in the .NET environment. It is (was) a hack
developed by Borland back at (AFAIR) IB 4.0, long before asp or .NET had
ever been thought of, to simulate the "direct local connect" that was used
by their iblocal DLL. IBLocal was a library that shipped with their Delphi
1 and C++ 4.5 products. This was a single-instance server that loaded from
the IDE. Applications literally did connect directly and you got one client
connection. Multi-threading Delphi 1 apps was a non-issue.
When they began distributing Superserver, they changed this "Windows local
connect" mechanism to be an emulation layer that could be accommodated by
the client layer as though it were a network protocol. They referred to it
as "IPServer" ("Inter-Process server", nothing to do with Internet protocol
) because it manages the database engine and the client layer in the same
inter-process communication space. That's the reason shared sessions are
not thread-safe.
As to multiple threaded sessions in Embedded being "perfectly safe", I'd
certainly be interested to hear actual load-testing evidence of that,
instead of hyberbolic claims and hearsay. All I've found so far, under lab
conditions, is that the server and the clients will crash under fairly
minor thread-load, i.e <10 threads performing trivial operations on my
workhorse Intranet server, a 455 MHz PII Celeron with 384Mb RAM. The same
and greater loads on the same gear under Classic or Superserver, connecting
via localhost, don't suffer from this problem. What's more, there is no
difference in performance, at least on this fairly low-spec setup.
I continue to regard v.1.5 Embedded as somewhat experimental and, at best,
a staging-point on the road to the more robust XNET implementation that
Dmitry planned all along. I don't think it is overly responsible of people
to make the kind of claims that Nando does regarding the Fb 1.5
implementation, without citing some numbers.
Helen