Login | Register
My pages Projects Community openCollabNet

Reply to message

* = Required fields
* Subject
* Body
Send reply to
Author (directly in email)
Please type the letters in the image above.

Original message

Author Cameron Brunner <cameron.brunner@gmail.com>
Full name Cameron Brunner <cameron.brunner@gmail.com>
Date 2007-09-24 22:25:07 PDT
Message memcache knows nothing of relationships, update a parent, the children
need to be updated too, there in itself lies a HUGE issue. David has
come up with a concept on how to handle this somewhat but on a site
with a lot of updates, its completely useless to add a caching layer
in this respect.

Anyway, my 2c, propel is the wrong place to be doing this for the most
part, i would seriously reconsider the level you are trying to
implement memcache at at this point in time. You could always create a
wrapper to BlahPeer::doSelect that had an optional cacheTimeout
variable that let you set a static timeout for the cache but... i'm
not a fan of time based caches, if they aren't intelligent there is
little point a lot of the time. Anyway, good luck either way.

On 9/24/07, Alexander Kahl <akahl at iconmobile dot com> wrote:
> Hi Pedram
> On Sat, 2007-09-22 at 18:26 -0400, Pedram Nimreezi wrote:
> > I have a lot of experience with memcache... it was definitely not
> > written to handle this...
> To handle what exactly? According to its docs, It was written primarily
> for caching frequent DBMS requests and load-balancing the results
> between several involved memcache servers.
> Do you mean it wasn't written to handle every single DBMS request
> possible?
> > but be that as it may I'm pretty sure it can still be done, it
> > would probably require the chaining of invalidators along with validators in the
> > cache aspect...
> > btw I'm the one that's optimized propel for opcode cache
> > accelerators... it's just
> > not a recent version.... summarily I've learned that the bottle neck
> > is always the
> > database and not how you connect to it... thats why PDO in my opinion
> > is overrated
> > in this context....
> Is this related to the actual discussion? I don't get the point of how
> the DBMS abstraction layer is involved here, sorry.
> > you're just not gonna get more performance from the database
> > no matter how much faster you request or convert the data.... increased speed at
> > this tier level is completely application level logic... also if you
> > extract objects
> > from memcache you still need to include the source files so it's still
> > not as if you're
> > pulling data objects hot from the grill...
> You mean requesting memcache data still requires to include Propel's
> generated files to get the actual related request..?
> --
> alexander kahl _ developer
> iconmobile GmbH _ methfesselstr. 30-36 _ 10965 berlin _ germany
> phone +49 30 886633 212 _ fax +49 30 886633 150 _ mobile +49 178 8279256
> akahl at iconmobile dot com _ www.iconmobile.com
> local court charlottenburg _ hrb 88308
> managing directors _ thomas fellger | stefan kirschke

Cameron Brunner

Want a better web browser?