Hi, I am interested in the 2 I) option. Separating only-read or read-write actions is simple. Even, we can do cache things more easily when we know which action is read-only.
Here is my thought: 1. Setup 2 EntityManager for master and slave, and the default will be the master one. This is pretty easy and works great. 2. Recognize which action is read-only. We can recognize it by the http method or just set it manually. 3. Change the default EntityManager to master or slave at the beginning of every action. I don't know how to do this actually. regards, sliver Lukas Smith於 2010年12月12日星期日UTC+8下午11時23分44秒寫道： > > Aloha, > > Soonish I will have to start setting up master/slave in my current > Symfony2 project. > We are using PostgreSQL 9.0 with hot standby, which for the topic at hand > is more or less the common MySQL setup. > > Aka you direct all of your writes at a master server and all your reads to > the entire DB pool (or just the slaves). > The main challenges to overcome: > 1) send writes to the master > 2) prevent issues with replication lag > > One could use MySQL proxy or PGPool to magically handle this, though > PGPool is a bit problematic since it doesn't realize that a SELECT > NEXTVAL() is actually a write. But using an ORM like Doctrine makes 1) > fairly easy to deal with in the application layer. > 2) is a bit more interesting. > > For 2): > Replication lag can affect things in two ways: > I) doing writes based on stale data from a slave, aka queries that are > done inside the request before the write > II) doing reads after the write that would fetch stuff that was written > > For 2 II) > In my current Doctrine 1.x using project I addressed II) by simply > pointing all queries (reads and writes) at the master from the point of the > first write. This way there would never be the risk that for example a user > adds a new comment and when afterwards the list is read from the DB it will > be read from the master. However this solution obviously falls flat on the > face when using the "standard" approach of redirecting after a form > submission. A solution here is to write a flash message to the session that > the request should be handled with reading from the master. > > For 2 I) > Here things get a bit more tricky. This essentially requires clairvoyance > aka the ability to predict of the request will be doing writes and > therefore using the master for all reads even before the first write is > issued. I have been thinking that it should usually actually be possible to > define on a per route (or per action) basis if the request could lead to a > write. Aka in some cases a validation error might prevent the write, but > even in that case you will likely want to be doing any reads during the > validation to be send to the master (for example to check if the username > is unique in a user registration). So I was thinking of adding some hint > into my route's to tell Doctrine if it should consider this to be a write > request and therefore decide if to point all queries at the master or if it > should use the normal read pool. > > Comments? Feedback? Solutions? Patches? > > regards, > Lukas Kahwe Smith > m...@pooteeweet.org > > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
