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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
