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. 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? What Transfer instance is now inside that object? I thought Transfer objects kept a reference to the Transfer instance that created them. This needs to be handled inside Transfer such that save/delete() is done with a different datasource than get()/read*(). It's quite common on high traffic sites to use many slave database instances that are very fast for reads and handle writes separately in a different database instance. All the big social network sites I know do this (Facebook, Myspace, deviantART). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
