P,

Hmmmm...... Yes some good thoughts in there. But..... There always is......

- I agree that a broadcast socket type solution is just "too hard".....

I kind of like your idea of central server and messages however.....

- My environment does not allow me to put down "servers" to do just DB work.
We have limited space (Our stuff typically lives in a TV truck. To
understand the space constraint. Put 5 towers on your desk together with
mice, KB's, monitors etc. and then sit 5 people in front of it. That should
give you some idea.... *grin*)  and as such each machine performs a function
and where necessary doubles as a "server". Because each machine has real
time functions to perform, server processes must not be too possessive in
terms of resources. Also the boxes are NT WKS and I am not sure that MSMQ
will run on that.

- Also when sending a "GET" message, I would still like that to be a SQL
request so that I can get data into say a TQuery so that I can still use the
functionality of DB Aware controls and the BDE/ADO/IBX etc. Not sure how I
would handle. Workstation1: "I need some data server1" Server1: "Wait. Let
me check that I have the latest data" Server1 "Hey Workstation 1 you can get
your data" Workstation1 executes SQL or whatever......

> Using this mechanism you can have as many servers as you like.

Sounds a bit like MIDAS, nTier to me..... Trying to stay away from that if I
can.....

------------------------------------------------------------------------
--Donovan
Donovan J. Edye [www.edye.wattle.id.au]
Namadgi Systems, Delphi Developer
Web: www.namsys.com.au E-Mail: [EMAIL PROTECTED]
Voice: +61 2 6285-3460 Fax: +61 2 6285-3459
TVisualBasic = Class(None);
------------------------------------------------------------------------


> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Peter G Jones
> Sent: Wednesday, 19 January 2000 22:54
> To: Multiple recipients of list delphi
> Subject: Re: [DUG]: Interbase Issues & Questions.....
>
>
> Very interesting problem.  Someone please shoot me down if I'm talking
> rubbish but this is how I'd do it.
>
> I think it is safe to rule out db replication as it's too slow and not
> real-time enough.  Sockets will provide an instant point to point
> link but
> to have one machine send a packet to all other machines would be
> tricky and
> if one of the machines is down then you could get into a lenghty time-out
> process.  There is also problems with a station not doing the
> correct thing
> and the database somehow getting out of sync.
>
> I think the soltion is to stick with 1 copy of the database on a central
> server.  You then need to have a server process that will
> receive, forward
> and process messages from each workstation. The messages would be
> add data,
> modify data, get data etc.
>
> The add/change/delete type messages would also be sent to a
> redundant server
> which would duplicate the same actions form the workstations.  If each
> server starts with the exact same database, the end result should be the
> same, but to be 100% sure, you need so serialization mechanism.
> Each unique
> message would need a serial number allocated by the server
> process.  You can
> then check on the server for messages in sequence and missing
> messages.  For
> example, if message 1 is add data from workstation 1 and message 2 is get
> data from workstation 2 then you know you must process message 1 before
> message 2 as it might be the same data.
>
> Now, WHEN (not if) the 1st server crashes, your workstations
> should be able
> to automatically swap to the next server.
>
> Using this mechanism you can have as many servers as you like.
>
> The only question is how you deliver these message and the only 100%
> gaurenteed method I know of is to use a Message Queue server (IBM or MS).
>
>
>
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
>
> ------------------------------------------------------------------
> ---------
>     New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
>                   Website: http://www.delphi.org.nz
>

---------------------------------------------------------------------------
    New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
                  Website: http://www.delphi.org.nz

Reply via email to