There are several problems that arise from splitting reads and writes superficially, particularly if there is MySQL replication involved (I assume that's the case). For instance, you may write to the RW database and then read from the RO database before the update replicated.
What I generally do is instantiate table-gateway objects with the RW DB connection if I think I'm gonna need to write. If one or two reads happen to the RW database, that's no disaster. The RO connection is then used as default.
I guess one possibility would be to switch the table-gateway object into 'write mode' if an update comes through, and subsequent reads happen from the RW database, but there are several other ways to skin this cat.
- Neil
On Fri, Aug 28, 2009 at 9:14 AM, Jean-Michel ANDRE <jean-michel.andre@infolegale.fr> wrote:
Hi,
Sorry if this question has already been addressed (actually I've found this
:
http://www.nabble.com/OOP-Design-question-related-to-Zend_Db_Adapter-to21754
135.html, but nobody answered to william0275).
I would like to provide an abstraction layer so that read db queries would
be routed to one server (say A) and write queries to another server (say B),
so that it is completely transparent to developers (they would continue to
use $db->select(), $db->insert(), $db->update() and $db->query() as usual) .
Is there a classical solution for that ?
Jean-Michel
没有评论:
发表评论