That is correct. In our case we've audited our code for transactions and all of ours are single statement trans.
It's pretty typical for read/write splitting to forbid multiple-statement transactions as a cost of doing it. -J Sent via iPhone Is your e-mail Premiere? On Sep 1, 2010, at 7:15, Itamar Turner-Trauring <ita...@itamarst.org> wrote: > On Tue, 2010-08-31 at 20:54 -0600, Jason J. W. Williams wrote: >> That's one way of handling it. Another way is to wrap the library so >> it does the splitting automatically. The advantage to the latter is >> not making mistakes where you accidentally use the READ connection for >> a write. > > That sounds like a bad idea. You want to send reads to the write server > if you're doing so as part of a transaction that does writes, otherwise > in some cases you'll end up with wrong results. > > For example, consider a transaction that inserts a row into a table, and > then does a select to count the number of rows in that table. If you > send the latter to a replicated read-only server, the result will be > incorrect, since it will not include the insert (which hasn't been > committed yet). > > So, to repeat: you should only use the read server for operations that > are read-only. Which means some reads will go to the write server. > > > _______________________________________________ > Twisted-Python mailing list > Twisted-Python@twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
