To turn that around though.. you could use the
getDatasource().setCurrentThreadDatasource("writeDatasource");
In combination with the Transfer Events to change your datasource details
transparently.
This would probably provide you with a much more flexible solution, as you
could start changing all sorts of details depending on what event you are
running.
Just trying to think of something that will serve if people had, I dunno,
something weird, like 4 different DBs or something ;o)
Mark
On Sun, Jun 28, 2009 at 5:37 PM, Elliott Sprehn <[email protected]> wrote:
>
> On Jun 26, 4:21 pm, Mark Mandel <[email protected]> wrote:
> > > What Transfer
> > > instance is now inside that object? I thought Transfer objects kept a
> > > reference to the Transfer instance that created them.
> >
> > They keep the Transfer instance that was created with them.... oooh.. I
> > start to see the problem. While the cache is shared, the object will
> always
> > make queries against the datasource it was originally created with.
> That's
> > no good for this scenario.
>
> Bingo. The locks weren't what I was talking about. :)
>
> >
> > Maybe changing datasource details on a per thread basis is actually the
> > ideal way to go then.
> >
> > So you could have the read DB as the default database, and when you are
> > ready to switch, you could do:
> >
> > getDatasource().setCurrentThreadDatasource("writeDatasource");
> >
> > getTransfer().save(fooObject);
> >
> > ...
> >
> > Anyone see any issues in that approach?
> >
>
> One major issue I see with that is it requires you to bleed the
> Datasource all over an application. The datasource isn't available on
> Transfer, only on the factory. It's no drop in solution, and you lose
> the abstraction of the datasource name you currently get with the XML
> or Configuration object.
>
> It's especially hairy on an existing application where you'd need to
> go and modify every place that talks to Transfer to manually change
> the datasource name. And make sure to add a try catch each time else
> you might leave the wrong datasource on a thread.
>
> You couldn't handle this with AOP either, because if you wrapped every
> save method with an advice that changed the datasource and then
> changed it back, that method could potentially call methods for
> validation or any number of other things on the object, causing a lazy
> load of a collection or a proxy, and again issuing queries against the
> writing datasource. You'd have to be extra careful and it'd be messy.
>
> If this was handled in the main transfer configuration with two
> datasource names then any existing or future application can have this
> added scalability feature without any extra code, just a few more line
> of XML or an extra method call on the Configuration object.
>
> <?xml version="1.0 ?>
> <datasources>
> <datasource type="read">
> <name>fastreplicated</name>
> <username></username>
> <password></password>
> </datasource>
> <datasource type="write">
> <name>slowwriting</name>
> <username></username>
> <password></password>
> </datasource>
> </datasources>
>
> >
>
--
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
-~----------~----~----~----~------~----~------~--~---
