> > OK - so from this description, superserver should handle it
> handsomely. One
> > connection, 250 updates every 5 minutes.. piece of cake for FB.
> > There must be some else happening..
> > you say multi threaded application. Are making sure you use a
> separate
> > connection for each thread?
> > You're kinda contradicting things here now... how many threads - so
> how many
> > connections?
> > Alan
>
> Ok, I will give you the complete overview.
> It is a bandwidth manager (internet gateway) software which controls
> QoS policies. It is connected to a big-big LAN (250 or even more PCs).
> All are trying to connect to the internet. When the application
> starts, it will capture the packets (pcap) and try to authenticate
> (based on IP, MAC, VLAN etc.). If there is not session open for a
> ip/mac, it will start a new thread for authentication. This
> authentication is done against firebird DB. Once authenticated, his
> session starts, which is updated to the db every five minutes. Only
> the authentication requests are multi-threaded, thread is terminated
> on authentication. There are no dead threads etc. Updates are done by
> a single thread one by one.
> Then it becomes a routine, somebody logs in, somebody logs out (idle
> time out etc.)
>
> Firebird handles the initial load (25-30 threads, thread pool)
> without any problem.
>
> On each request (authentication, update, close) I call a function,
> which attach to the database, starts a transaction, updates, commits
> the transaction and then detaches from the database. Error checking
> is done for deadlock and any other errors. Transaction is rolled back
> on a failure.
>
>
> JS

yes - I'm familiar with all this - I wrote the MSSQL end of one of these for
a radius server.
FB should have no issues at all with it. The updates are light and there
should never be any hold up.
Something else is at play here - it's not Firebird - it has to be your
application somewhere.
Alan