Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re: Re^2: Recent slowness and outage (IPC cache)

by perrin (Chancellor)
on Jan 17, 2003 at 05:01 UTC ( #227604=note: print w/ replies, xml ) Need Help??


in reply to Re^2: Recent slowness and outage (IPC cache)
in thread Recent slowness and outage

Do multiple updates to the same node really happen that often? I thought people were not usually able to edit the same node.

Maybe I'm misunderstanding, but I don't think the node cache is the right place to implement your idea about saving the original version. Don't you want to save the version that this user originally received, rather than this process? There's no guarantee that a user will even be on the same machine when their form submission is processed. Seems like you would have to do it based on session and keep it in the database.

Having a separate cache for nodelets (or anything else) is no problem. You can have as many caches as you want.

Finding a solution that works across all the machines in the cluster is harder but possible. It would require something fancier like messaging daemons or some database trickery. Just making the cache multi-process is enough of a challenge for now.


Comment on Re: Re^2: Recent slowness and outage (IPC cache)
Re^4: Recent slowness and outage (IPC cache)
by tye (Cardinal) on Jan 17, 2003 at 05:31 UTC

    You vote for my node and you change my XP, your XP, and your vote count. I vote for your node and I change your XP, my XP, and my vote count. Yeah, user nodes get updated simultaneously all the time. Other nodes as well.

    I'm not talking about users editing the text of the same node at the same time. The few situations that support that implement more complex locking.

    The problem is not that the user made decisions about how to update a node based on old data they saw. Please read the Last checked flag not updating? thread which covers this problem in more detail. Yes, you are misunderstanding. (:

    The changes to the node happen during the course of rendering a page. What I need to keep track of is the state of the node between the "get node" and the "save node".

    Ugh. I just realized that we have another race to deal with. You could have this happen:

    • process X does "get node P"
    • X changes a field in node P
    • X calls a routine...
    • process Y finishes an update and does "save node P"
    • Y's node cache saves the changes and increments the version number of node P
    • the routine X called calls "get node P"
    • X's node cache notes that P's version number is old and rereads the node into the cache, clobbering the previous changes X had made
    • X finishes updating and does "save node P"
    and X's changes are lost.

    So "get node P" also needs to be made smart enough to not reget the node. My first thought was to compare the two versions of the node and not reget if the node is changed. But I think a better idea is to only reget a node once per page load (more efficient, more robust). Well, I'll chew on that some more...

                    - tye
      Double ugh. We're getting tangled up by limitations of MySQL when this was designed (lack of transactions and row-level locking) and limitations of the Everything code (writing the entire node at once). I don't know if it's possible to truly fix this stuff without fundamental changes. Maybe I should just focus on making a shared nodelet cache.

      Anyway, as I understand it you want to get the node, keep a local copy, do the updates (which currently all modify the version of the node in the cache), and then compare that to the original. Unlike the current in-memory node cache, a shared one based on Cache::Mmap would not update the node in the cache until it is explicitly saved back to the cache, i.e. in-memory updates do not modify the cache. I'm not sure if that helps any or not. Depends on what the update code does.

        Having an unmodified copy of the node is nice. But having some other process being able to update it out from under me pretty much defeats the entire purpose. (:

                        - tye

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://227604]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (9)
As of 2014-11-27 14:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (186 votes), past polls