--- In firebird-support@yahoogroups.com, "Alan McDonald" <alan@...> wrote:

>
> > --- In firebird-support@yahoogroups.com, "Alan McDonald" <alan@>

wrote:

> > >
> > > > Hi there,
> > > >
> > > > I have a server running on embedded firebird 1.5 and firebird.net
> > > > provider 2.0.1. There were 160 clients reporting data to the

server.

> > > > After running for several weeks, the server was stuck, with

100% cpu

> > > > utilization without doing any real thing (all client

connections to

> > > > database were timed out.)
> > >
> > > firstly, can you clarify what you mean here?
> > > embedded is not a server product. Do you actually mean the full
> > Superserver?
> > > or Classic server?
> > > OR do you mean your very own - roll-your-own custom tcp server

to which

> > > clients connect, which uses the firebird embedded superserver as
> > it's back
> > > end?
> > > Alan
> > >
> >
> > Sorry I didn't state it correctly. It's the 2nd case: My server is a
> > tcp server handling client connections, and uses embedded firebird as
> > backend to save data.
> >
>
> in which case, I would be doing a very close examination of your

threaded

> connections. i.e. making sure every new user connecting to your tcp

server

> is provided a separate connection thru the server. I don;t know

exactly how

> this is done in the .net provider.
> Alan
>

May be a bit more detail will clarify this further. We have an
in-house Client/Server application. The server is a .NET 2.0 NT
Service, runs as LocalSystem and uses embedded firebird to store data
on to a firebird database. It uses firebird ADO.NET provider and C#.
Each client connects to a TCP port. Each client is running on a
separate client machine that runs Windows Server 2003 and the client
itself is a .NET 2.0 based NT Service. We have our own custom protocol
between the client and the server. Once a client TCP connection comes
in and it issues a command to the server, the server then grabs a
firebird database connection from a connection pool to perform
database access and return results back to the client. There are no
user issues here since clients do not connect directly to the
database. The TCP server keeps database connections in a connection
pool and performs the requests on behalf of the client.