If you're not using the cache, I think you will find that the performance just isn't going to be up to scratch, especially if you are doing as many read operations as you say.
Generally speaking, a lack of cache tends to be a rarity, rather than the norm. Having dirty reads on the database with the cache active, scares me to no end, as it is way too easy to get a dirty cache, which will cause all sorts of issues down the road. Mark On Fri, Mar 6, 2009 at 1:55 PM, Dan Wilson <[email protected]> wrote: > Interesting use case, Nick. I'm not sure what I think about it. > > I can understand why you need to go the route you've chosen. I am not so > sure this belongs inside of Transfer. A large part of Transfer revolves > around the caching layer. > > What benefits were you looking to get out of using Transfer? > > > DW > > > > On Thu, Mar 5, 2009 at 9:21 PM, NickHaggmark <[email protected]> wrote: >> >> One additional thing I forgot to mention is that this new product is, >> for all intensive purposes, a duplication of an existing successful >> product with a few feature changes. We have a fairly short delivery >> time line for this implementation, so that is why I'm not able to >> completely redesign the back end. >> >> Thanks! >> >> Nick >> > > > > -- > “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 > > > > -- E: [email protected] 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 -~----------~----~----~----~------~----~------~--~---
