On Fri, Jun 26, 2009 at 5:18 PM, Elliott Sprehn <[email protected]> wrote:

>
> On Jun 25, 2:39 pm, Mark Mandel <[email protected]> wrote:
> > Of course the other option is - have 2 transferFactories, one for read,
> and
> > one for write, with an application scoped cache.
> >
> > That would work too ;o)
> >
> > Mark
> >
>
> It won't work because Transfer will do all kinds of queries when
> cloning, lazy loading, loading proxies and handling relationships.


Yeah, you're right.. this is a tricky problem.


>
> You'd end up doing lots of reads against the potentially very slow
> writing database. I'm also curious what happens when two threads call
> get() at the same time and access that shared cache?


That should be okay, because the locks are named, and since the name is the
same, one would wait for the other.


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

This needs to be handled inside Transfer such that save/delete() is
> done with a different datasource than get()/read*().


Yeah, I see what you are saying here, that is right.

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);

//add any other write stuff here

//would have to have a 'reset', so the details don't stay that way, because
of thread pooling.
getDatasource().resetDatasource();

If you wanted to be really cute about it, you would write CS AOP to manage
it too.

Anyone see any issues in that approach?

Mark

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

Reply via email to