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 <itamar@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