--- In firebird-support@yahoogroups.com, "jarrod_petz" <petz@...> wrote:

>
> >Events are useful for notifying other clients of changes to the
> >table. Presumably if you are allowing the user to continue working
> >until the data is ready, you this connection and transaction running
> >in a background thread. In this case, it would be easier IMO to let
> >the background thread synchronize with the VCL thread once finished
> >than to create an 'event object' that is waiting in another thread
> >anyway doing the same thing.
> What we are trying to do in asynchronous message passing between a
> server process which is running on a server computer and multiple
> client/workstation. The only other way I can see to do this would be
> to add network code to our server process rather then rely on the
> database for communications. Is that what you are suggesting?

I am a bit confused as to whether your system is 'client-server' or
'n-tier'. Is your server process simply another 'client' in a
client-server arrangement that your clients make a separate connection
to to initiate some other process, or how does this work?

Your first point was:

> 1. A client is going to make a request to a server process that will
> take a long time to return data. Rather then block the client until
> the data is ready we allow them to continue working. The client will
> register an event in the Firebird database and start listening to
> the event before making the call to the server to start retrieving
> its data.

I take this to mean that your client machine contacts a server process
to do some work (a tier type model). But on the other hand, it is
connected to the database (a client server type model) listening for
the events that get posted.

I do not like exposing a database server across the net, although with
VPNs you could probably get it to be acceptably safe. Still, I do not
believe that the over-the-wire performance of Firebird is good enough
for us to consider a client-server deployment across an extremely slow
link such as the internet (although it may be good enough for other
folks applications).

The next thing to consider is that NAT makes a bit of a mess of
communications from the server to the client initiated by the server,
because you have multiple computers sharing a single IP address. It
may be technically possible to achieve, but the reason we did not go
down that track was that it would become a discussion point for every
implementation.

I can see several options. Your client process could contact your
server process in a background thread. Once the call returns, simply
synchronize this fact with the VCL thread, and then collect the data
of interest.

Tools like RemObjects could be used providing they work with your
version of Delphi. In fact with RO, you could create an asynchronous
interface with its own callback logic and do it all from the VCL
thread, but I prefer to keep the interface simple and contact the
server from a background thread.

>
> >Look in firebird.conf at RemoteAuxPort, and restart the service after
> >any changes. If you are using a secure channel, then you will have to
> >have in place the appropriate firewall rules to allow the server to
> >contact back to the client on that port.
> Sound good but if the NAT port forwarding rules drop out of the system
> or the connection is blocked by a firewall will it have the same
> effect as I do currently where when communications are blocked the
> Firebird server freezes/stalls/locksup and I have to kill it and
> restart it which is not good and disrupts all client connections.
>
>
> >We use a different approach in that the server stores in a holding
> >table the PK of the data that has been changed, and when the client
> >synchronises, we send this data down. It is a poll mechanism rather
> >than an asynchronous call, however we do not have to worry about
> >trying to make a connection from the server to a client through NAT
> >and whatever else, and have our system fall over every time some
> >goose resets all the rules on the router.
> We might just have to go polling as well for this but it seems a waste
> when the feature is in Firebird it just needs to not
> lockup/stall/crash the server when it can't get a connection and if
> possible be a bit more mindful of NAT/Firewalls when establishing new
> connections.

I agree it shouldn't crash the engine, I am not sure if there have
been some improvements or not in this respect.

Adam