> Where I would *expect* it to be a problem is when you
> have single queries that take a significant amount of time, rather
> than a large number of fast ones.

Yeah, long running queries, we generally try to avoid anyways, but I
suspect the blocking nature of FFI only exaserbates the problem.

> I'd think that this could lead, for
> example, to HTTP connections being refused if someone tries to access
> your application at the same time as someone else is in the middle of
> a lengthy search or complex report.

I think in theory you are right, but I think it must become
problematic somewhere beyond 5 - 10 concurrent users.

> If the ODBC C library has a
> non-blocking interface (which it must, surely), then you could write a
> plugin that used that instead of the blocking FFI interface we
> currently have and the problem would go away.

That couldn't be too bad -- right?  Well, if I get into trouble on the
FFI edition of ODBC I might explore this more.  For now, we are having
good successes using the existing library.

> Out of curiosity, what happens if you simulate higher loads (10 or 20
> or 50 concurrent users) with your app?  It would be good to get a real
> world sense of where the issue kicks in, so people can make better
> informed choices (like me, who until I read this message had more or
> less written ODBC off for use in web apps).

Yes, indeed. If I get a moment during the holiday season to explore
this I may.  Do you know of a good web stressing framework (that is
free ==> good == free ;-)?

Regards,

John