Hi Jason,

> It's not a flaw at all. In fact to do it the way you seem to
> imply would be
> a flaw in my opinion. Here's why.

Hmm, I think it _is_ a flaw that GDS32.DLL is not thread-safe.
Here are my reasons:
1) I have to use several connections in my multi-threaded
application. It would be sufficient to use one
connection - if GDS32 would be thread-safe. So I have
to waste resources as "workaround".
2) The FB developers intend to fix this issue. If it wasn't
a flaw, why whould the fix it then?
3) Over the years, I have seen lots of reports at support
forums where people reported errors which were a result
of the fact that they used threads with the GDS32.DLL.
So I got the impression that such a library is expected
to be thread-safe. (OK, this is a rather weak reason).

> What this boils down to is where the multi-ness is ironed
> out. It makes a
> whole, whole bunch more sense to have this entirely off loaded to the
> server's internal engine processing. To expect the server
> software to do it
> any closer to the client than it does is to subvert having
> the multi-ness
> handled in a way that allows all clients to be handled in a
> truly parallel
> manner. (as true as it can get anyway)

> If this doesn't click for you I'll try and expand on it.
> There is a concept
> here I'm trying to illuminate.

I think I understand what you mean, but I am not really sure.
If you have the time, it would be great if you could elaborate.

I agree that parallelizing database reads and writes is quite
unimportant for 98% of all client applications. And we don't
have to discuss server-centric programming, because we both know
it is quite the right way.

But for some programs, what you said above doesn't apply.
One little example: I have written a program which synchronizes
a Firebird DB with a non-Firebird-DB. I have no influence on the
contents of the second DB, so it is a very time-consuming process
to synchronize because the are no flags in the non-FB-DB which indicate
which rows were changed. The synchronization program scans the source
DB and makes insertions, deletions, changes and calculations for the
destination DB (Firebird-DB). The first version of this app gathered
all information and did some kind of batch processing. This took a
very long time, so I had to find a way to accelerate it. I found out
that using threads working on independent tables could speed the
whole thing up. Of course, I have to use one connection per thread.
Otherwise, it wouldn't work.
I cannot see the flaw in what I have done and I cannot see how the
speed of my application could have been improved in another way, either.
IMHO, there is no way to "have this entirely off loaded to the server's
internal engine processing".
The only flaw I see is that I have to use more than one connection for
this, but this is not my fault and I hope it will be fixed in the
future :-)

> In short, it is worth working with how it is. There's a good
> reason it is
> this way.

Hmm, I must disagree. But the fact that you are so sure about
it makes me think that I might somehow missed your point.


With regards,

Christian


PS: Feel free to e-mail me privately if you think this
is OT for the list.