At 08:59 AM 23/02/2007, Sean wrote:

>Rick,
>
> > > Given that you could have TCP wrapper functionality enabled if you
> > used inetd or xitend, why wouldn't you consider using that approach
>for
> > launching FB?
> >

Rick Debay wrote:

> > Our database is not a network service. It will quite happily run
>doing
> > useful things (up to a point) if no one connects. So we want the
> > database to start even with no connections.
>
>A database can't do anything without a connection!

Sean, he is talking about Superserver and I *think* he means he wants
the *server* running.

He's wrong about SS not being a network service, though. Even if he
has cron jobs attaching to the database, it must be through
libfbclient.so via localhost, since libfbembed.so doesn't work with SS.

>Maybe I'm missing something, but without some process establishing an
>initial database connection, a database will do nothing.

Following this dialogue between you two, where you (Sean) are talking
about xinetd (which doesn't apply to SS) and he is talking about SS
(which is a service in its own right and doesn't use xinetd) it's
easy to see how either of you could be missing something.

>After all, without the engine getting a connection request, the engine
>will never be opened.

True for Classic, not true for SS. If the SS engine process isn't
running, nothing can connect to it. The SS model spawns threads of
itself for connections, even those it creates internally for GC and
other tasks. All this is quite different to Classic, for which
xinetd starts a self-contained instance of the engine process for
each connection.

>Further, without an open connection, the engine will close the database
>file.

That's true, too. But Superserver itself doesn't shut down when
there are no connections to databases. In fact, when the last
connection detaches from a database, the engine might stay connected
to the database for a while, if it had a GC thread running at the
time of the last detach.

>I think you are trying to hide something, but in fact it is making it
>difficult to understand and solve your problem.

AFAICT, the "problem" is that Rick wants the ability to use TCP wrap
to fiddle about with the network settings during runtime, log
requests, IP addresses, whatever. From what I understand, TCP wrap
requires the executable to have a porthole to the application, that
it doesn't have now. What you are saying about xinetd is all well
and good for Classic, which doesn't even concern itself with handling
network requests. Since xinetd already has this porthole, for
Classic it's a non-issue.

This topic doesn't belong here in the support list at all. It should
be taken to Firebird-architect *forthwith*.

^ heLen