That JDBC load balancing option is pretty cool. I hadn't found that option yet and it looks like that may be a viable option for what I'm doing. Maybe this type of configuration really belongs in the JDBC level rather than the Transfer (ORM) level. Based on the options on the table, having a single write master and 2 read DBs balanced via round robin will probably work just fine. There are other strategies that some others may wish to use, but I have a healthy respect for dealing with replication issues and especially for how parallel replication, if configured incorrectly or non-optimally, can really suck performance and engineering time. Hence, I'm going to stick with a single write database as long as possible.
I don't even want to get into database sharding and I suppose if the application grows to need sharding, it may also grow past an ORM. Thanks for the help, at this point, I'm going to pursue load balancing from the JDBC level and see where that takes me. DW On Mon, Jun 29, 2009 at 5:28 AM, Mark Mandel <[email protected]> wrote: > Doing some more reading... > > There are some interesting ways to do this at a JDBC level: > http://gabrito.com/post/load-balancing-across-mysql-servers-using-jdbc > > But reading up on this stuff, I stand by my position that having a simple > 'read' and 'write' option is just not enough for a framework to consider, > and I can see the pitfalls of a event driven solution as well. > > Simple reading that article, they have discussed have 1 read-write master, > and 2 read-only slaves, which are round robin accessed. > > Considering I would figure it would be an eventual consideration of people > doing HA, it would seem to make sense to cover that sort of eventuality, > which a single read and write would not be able to cater towards. > > I'm starting to think, maybe something like this would be appropriate: > > <datasource> > <name>DefaultReadWriteDatasource</name> > </datasource> > <read-only strategy="round-robin"> > <datasource name="read1"> > <name>ReadOnlyDataSource2</name> > </datasource> > <datasource name="read2"> > <name>ReadOnlyDataSource2<name> > </datasource> > </read-only> > > And in that, when doing reads, it would round robin through the read-only > datasources, and then when doing writes, it would simply go to the default > datasource. > > For those of you who know more about HA than me, > > a) Would you only ever have 1 read-write master database? > b) What other strategies other than round-robin would you want for choosing > which datasource you would want next in the queue? > > Mark > > > On Mon, Jun 29, 2009 at 6:58 PM, Elliott Sprehn <[email protected]> wrote: > >> >> On Jun 28, 5:47 pm, Mark Mandel <[email protected]> wrote: >> > On Sun, Jun 28, 2009 at 6:39 PM, Elliott Sprehn <[email protected]> >> wrote: >> > >> > ... >> > >> > And a mechanism, to be able to switch between the credentials as >> neccessary, >> > which is far more flexibly than just 'read', and 'write'. >> > >> >> The complexity is more than necessary and requires much more work than >> just adding a read/write datasource. >> >> Again your solution doesn't stop reads on the writing datasource if >> some action that happens after your listener switches the thread >> datasource. >> >> This is not as simple as implementing a listener, it requires going >> back and making sure all your code doesn't cause those incorrect reads >> which is especially nasty if you have many listeners. Now you have to >> think about which listeners happen when and what they do. And even >> then that's not future proof since a listener from a third party for >> validation that is added at a later date might cause reads on the >> wrong datasource. You'd have to constantly be careful and double check >> all the interactions. >> >> I don't understand why you can't implement separate reading and >> writing datasources and still allow your >> setCurrentThreadReadingDatasource() method to exist. >> >> Your solution has lots of obvious caveats that significantly reduce >> the usefulness of the feature, and make it much more error prone. It's >> far less likely to get used, especially properly, and again it's not a >> drop in solution. You'd have to go back and double check every code >> path to make sure you didn't cause reads on the wrong datasource. >> >> > > > -- > E: [email protected] > T: http://www.twitter.com/neurotic > W: www.compoundtheory.com > > > > > -- “Come to the edge, he said. They said: We are afraid. Come to the edge, he said. They came. He pushed them and they flew.” Guillaume Apollinaire quotes --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
