I like to see MMbase in three layers.
1 User layer - thiu layer is user-centric and every action is based on
this user, his role and the security constraints. You could say this is
the bridge, because the cloud has a user and it applies the securtiy
constriants
2 Repository layer. This layer is used by all users and exposes all that
is in the repository. This layer maintains the model: builders,
typedefs, reldefs typerels oaliases, etc. Data which is in this layer
can be seen by all users. Data in the User layer can be specific for
that user (local modification).
3 Storage layer. This layer is responsible for pesistence and retrieval
of data. The repository layer uses this to store and retrieve nodes.
This layer decides how and when to interact with the persistent store
(database). It could use a cache instead of the trip to the persistent
store.
At the moment, the processors are called in the bridge which is
user-centric. A procesor should work just for one user and one request.
The loop example is executed for in one request and could be a local
modification until it is saved to the repository layer (this is what a
transaction does).
In my previous reply I made a small difference between StorageManager
and storage layer. The StorageManager is the accesspoint to the
persistent store and also seen as the access point to the storage layer.
In my defintion above this should not be the same. When you tell the
persistent store to change (StorageManager). then it has to update. No
matter what tha value is. I thought that MMObjectNode has code to
determine that the value is equal and should not call the storage for
this field.
IMO it is a quick fix, because it solves somthing in the wrong position
of the system When it is really desired to delay the database call then
the storage layer should make this decision. The processors are just to
high on the chain to be able to make a good decision. With MMbase we try
to reduce the load on the database, because mmbase can easily create a
starvation on database resources. But I don't think this is the database
killing example. It is more the many small select statements which use a
new db connection which kill the database. This update example is just
being nice for mmbase itself (caches and events).
Nico
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.
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
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
