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.
> The example is not very realistic too. A poll will be updated by
> different users, which means different cloud sessions. Every cloud
> should "commit" its changes to the system before it finishes the
> request. A Transaction object would have worked to speed up the
> loop-code too. The setValues and node commit are delayed until the
> transaction commit takes place.
Of course, the example is a bit silly, because I update in one loop the
same field very often. But it would not have made any difference if it
would have been very many requests, with very many sessions and so on. I
don't understand how a transaction would have helped, because I would have
very many transactions then, too. The idea is to summarize several updates
on the same value in one database update with the last value.
> 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.
>
> IOW, it is a quick fix for a more fundamental problem or it can be
> achieved by already existing code.
You may be right, but you didn't really convince me. The more fundamental
problem is I think 'mmbase persists everything to the database immediately,
while that in some cases it not worth the overhead'. Since I cannot think
of a generic algorithm to determin in which cases some update-collecting
can be acceptable, I thought that simply indicating it like I proposed with
these 'processors', would not be so wrong.
Btw, I don't foresee that the poll I just implemented, will actually be
that much visited that something like this is essential, so for the moment
it is rather academic to me, but I can imagine situations where it is
important to spare the database a bit like this.
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.
Michiel
--
Michiel Meeuwissen mihxil'
Peperbus 107 MediaPark H'sum []()
+31 (0)35 6772979 nl_NL eo_XX en_US
_______________________________________________
Developers mailing list
Developers@lists.mmbase.org
http://lists.mmbase.org/mailman/listinfo/developers
