Alban Hertroys wrote: > Michiel Meeuwissen wrote: > > Nico Klasens wrote: > >> It sounds a wierd hack to me. > >> > >> Why would a delayed update be 10 times faster than a normal update? I > >> would have expected it to be a little less. It can't be the database > >> overhead so it must be code in MMbase. My guess is the eventsystem and > >> cache updates. > > > > I mean that if you change a field a very often, that it may > > be enough to write it to the database only once per 10 seconds. Especially > > if it is no big deal if a few updates are lost, if in those 10 seconds the > > system happens to crash or so. > > If I understand correctly, you want to queue up concurrent updates and > only store the latest value of a field instead of updating it each time. > Looks like you're trying to implement "command queueing".
More or less, but not entirely. It is more something like 'command canceling'. If i issue 'set field x to value z' one second after 'set field x to value y', then I could have well not executed setting it to y, and only set it to z, if only I kept that in memory for one second. > A time interval seems relatively complicated, and may result in rather > long queues on fast(er) servers. It may cause problems with the servers > of next year... I don't think so, because my queue does not actually grow very much. If an update is received on an already queued update, it simply updates the update... So the queueu can never grow longer than, in my case, the number of polls on the web-site, which should be a very limited number. > >> And yes, a change on the StorageManager should mean an update on the > >> database. It is called a 'storage layer' for a reason :) > > > > I mean: if I can predict that nothing will really change, should it still > > happen then? If i know that in the database is '1234' and I get the > > instruction to update that to '1234', can I be so free to do nothing at > > all? It is possible that in some situations that would give issues, but I > > don't see it yet. > > Do you _know_ that nothing changes in the database? It is easy to check > that nothing changed between the first and last queued values, but that > could still be different from what's stored. > > OTOH, Checking a (the first?) queued value with what's in the database > requires a lookup, which is also required once you perform an update to > store the last queued value - I don't see the benefit in doing that. A > database lookup is required in either case. The assumption is that what was originally queried from that database when creating the MMObjectNode is still in the database. MMObjectNode contains 2 value maps 'oldvalues' and 'values'. 'oldvalues' should represent that database. This assumption should be correct when using one webapp. But see also bug: http://www.mmbase.org/jira/browse/MMB-411 I'm not sure it can still happen, because IIRC I did some updates back then targeting this issue. In general it is bad if in the same MMBase there are 2 MMObjectNode instances which represent the same record in the database. > > For many updates to different nodes I would like to use database > > transactions and/or the currently unsupported 'bulk-update' (update where > > number > > in (... etc)) commands, but that is not the issue I'm addressing. I meant > > frequent changes on the same value, as may typically occur in > > counter-fields ('view count' fields?) in e.g. polls and fora. > > It would be interesting to see how many visitors/s you need to start > seeing the benefit of queing the counter values. Yes. But the whole thing grew from my dogma that a normal hit on a normal page should never result in any query in the database, and that any shift of load from the database from the app-server is a good idea, because app-servers are easier to load-balance (well, I don't know yet excactly what could go wrong with my delayed-stuff when load-balanced either...). This was primarly meant as a kind of experiment on what would be possible to create a sort of cache for updates too. In most cases it is a bit senseless, because nodes don't generally change very often, and if they do you can as well execute it immediately, because it must happen any way. But I felt that this case was different. Michiel -- Michiel Meeuwissen mihxil' Peperbus 107 MediaPark H'sum []() +31 (0)35 6772979 nl_NL eo_XX en_US _______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
