Aaron Stone wrote:
http://www.dbmail.org/dokuwiki/doku.php?id=multifoo_architecture
^
On Wed, 2006-10-25 at 02:29 -0700, Aaron Stone wrote:
I want to draw some spare cycles in the backs of people's heads over to
a new page I just set up in the Wiki:
http://www.dbmail.org/dokuwiki/doku.php?id=mulifoo_architecture
What I want to do here is nail down a design for multiplex, multithread
and multiprocess operation to ramp up DBMail's scalability potential.
Aaron
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
Not knowing the details of the current source all of this is probably
wrong ;->
My thaught would be a state machine based setup. Each connection has its
status information contained in a nice type. Use an event driven library
to trigger progression through states for each "machine". SQL I/O can be
handled by a seperate thread/pool thereof, using shared memory to pass
that info to the logic side.
SQL connections can be throttled on a per server basis then, so the one
db server can connect to a bunch of back end databases that focus on
whats needed for the db's. The managment process can track which user is
on what servers, giving you the ability to move backend databases
without disrupting active user sessions.
With the state machine archetecture you could also (in theory at least)
migrate a running server to another server without loosing client
connections (if you were running through a smart enough proxy, loosing a
proxy server would still be problematic I thinks as the TCP connection
would be broken, I wonder if XEN could be used as a "live backup" in
that instance).
