Subject | gds32.dll thread safety...still...again |
---|---|
Author | Rob Schuff |
Post date | 2001-07-05T15:25:06Z |
Hi folks,
There still seems to be a great deal of confusion in the ASTA community
(myself included) regarding the use of InterBase multi-threaded clients on
an InterBase server. There is confusion as to the details of the issue as
well as the timeline for getting it fixed. At one point Anmn H. indicated
it would be a pretty easy fix, but Jim S. probably had to do it and he had
other commitments. Here is what I think is the generally accepted opinion
as to what the issue is.
***********
I've seen this comment repeatedly here and elsewhere. But something
just doesn't make sense... If GDS32.DLL is talking to the server using
TCP/IP, I don't see any way by which it could possibly "know" that it's
on the same CPU as the server. If it somehow can, that would be a
serious design problem.
The impression I am under from the IB world is that if you use a network
connection mechanism (anything but the infamous "Y-valve" local
connection debacle), and you use one connection per thread, it all works
just fine (thread-safe) on a single machine. I have never been able to
reproduce any thread-unsafety myself in that configuration. We've used
ASTA + Interbase in that configuration at ASTA training, it worked fine
there also.
The "one connection per thread" is a key element here. When some people
say "thread-safe", they are asking to have one connection be sharable
safely across concurrent operations in multiple threads - neither IB nor
any other database I have used works that way.
[ Kyle Cordes * kyle@... * www.kylecordes.com ]
***********
Can somebody please clarify the issue and address the issues surrounding a
fix? I was unable to find the bug listed in sourcforge. This seems like a
rather important isssue and solving (or at least fully describing it) for a
community that uses IB/FB extensively as well as a commercial vendor who
supports IB/FB as the ASTA folks do seems like it should be a high priority.
I will be happy to forward the ersponse to the ASTA folks.
thanks!
Rob
---------------------------------------------------------------------
Robert Schuff Bull Run Software
rob@... Portland, OR USA
---------------------------------------------------------------------
There still seems to be a great deal of confusion in the ASTA community
(myself included) regarding the use of InterBase multi-threaded clients on
an InterBase server. There is confusion as to the details of the issue as
well as the timeline for getting it fixed. At one point Anmn H. indicated
it would be a pretty easy fix, but Jim S. probably had to do it and he had
other commitments. Here is what I think is the generally accepted opinion
as to what the issue is.
***********
I've seen this comment repeatedly here and elsewhere. But something
just doesn't make sense... If GDS32.DLL is talking to the server using
TCP/IP, I don't see any way by which it could possibly "know" that it's
on the same CPU as the server. If it somehow can, that would be a
serious design problem.
The impression I am under from the IB world is that if you use a network
connection mechanism (anything but the infamous "Y-valve" local
connection debacle), and you use one connection per thread, it all works
just fine (thread-safe) on a single machine. I have never been able to
reproduce any thread-unsafety myself in that configuration. We've used
ASTA + Interbase in that configuration at ASTA training, it worked fine
there also.
The "one connection per thread" is a key element here. When some people
say "thread-safe", they are asking to have one connection be sharable
safely across concurrent operations in multiple threads - neither IB nor
any other database I have used works that way.
[ Kyle Cordes * kyle@... * www.kylecordes.com ]
***********
Can somebody please clarify the issue and address the issues surrounding a
fix? I was unable to find the bug listed in sourcforge. This seems like a
rather important isssue and solving (or at least fully describing it) for a
community that uses IB/FB extensively as well as a commercial vendor who
supports IB/FB as the ASTA folks do seems like it should be a high priority.
I will be happy to forward the ersponse to the ASTA folks.
thanks!
Rob
---------------------------------------------------------------------
Robert Schuff Bull Run Software
rob@... Portland, OR USA
---------------------------------------------------------------------