Gareth Bult ha scritto:
> Urm,
>
> When you say doesn't scale .. exactly how many clients do you have and how
> quickly do they need to know about updates?
>
> Let's say for the sake of argument your SQL server can process 2000 moderate
> queries per second (not unreasonable) and you want to poll every second with
> 10 clients. This really isn't much of an overhead .. ???
>
> Bear in mind MySQL has a query cache .. if you go 100 seconds with no
> updates, 10 clients will make 1000 SQL requests, but these will be identical
> and the server will probably only have to do any real work once ... so ... ??
>
> This for a 24 hour dinghy charity race that happens once a year.
>
> There are programs that put race data into a mysql database
> ("providers") and other programs that display the data in different ways
> ("users") depending on what audience is targeted.
> Ideally, there could be any number of providers and users on the same
> machine.
>
> How would a "user" know that new data is available? Traditionally, I had
> been polling the database but it does not scale very well, particularly
> if new data needs to be displayed fairly quickly.
>
> What I had done now is to have each provider (after changing data in the
> db) send a udp broadcast to the whole subnet saying "to whom it may
> concern, table x in db y has changed." It does not need to know who the
> users are. Likewise, the users do not need to know who the providers
> are. All they need to know is where the database is.
>
> It is very simple and worked very well, except I could only have one
> user per machine.
>
> Ideas, anyone? Could database triggers do the job?
>
> Best Regards,
> Werner Dahn
>
I agree with Gareth...
but assuming that you have many "tables x" in many "db y", you could
make one more table in a common database, where to put log records in
the form "datetime - table x in db y has been updated". Every user can
then do a select on this single table, selecting on "datetime >
last-time-I-readed-this-log".
Otherwise, as Benoit says, a single daemon listening in every machine
could service many users. But it is not so simple to build a reliable
system; if a broadcast packet fails to reach a machine, there is no easy
way to know about. If broadcasts fire often (say, every 10 seconds),
this could be not a problem. So, the database solution, if viable, is
guaranteed to work.
Cheers,
Doriano
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gambas-user mailing list
Gambas-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-user
