There are cases in which it makes sense to synchronize your caches, and there are cases in which it doesn't make sense.I don't think you will want to synchronize caches. Normally you would have different caches because you will have different sites running in different webapps on the same database and MMBase cloud. These sites will generate different cache entries.
Daniel already suggested to put some more information in the NodeChangeEvent to be able to see if the changedNode is of any interest. You can also work with MMBase clusters in which you specify which web applications should be notified by each other.
I think that multicast still is a good way toWe at the VPRO are already thinking about setting up Multicast tunnels because the servers are not located on the same network. Another big problem is that messages can get lost, and this makes the nodeChange mechanism ungaranteed, and that causes MMBase to behave in an undefined way which is unwanted. I agree that people should be able to use it if they want. But i think a better, more professional alternative would be nice.
message other MMBase instances about changes on
the same data they share. It is low level and
does not demand a lot of resources. Problem is
its bad thread design that forces a lot of
threads to be started at the same time -> some
threads don't get initialized because of memory
shortage -> some messages don't get delivered.
There are of course other communication mechanisms possible, like between:
1. MMBase instances that share the same database. 2. MMBase instances that do not share the same database, but that share a piece of data between them.
Typically the first variant will be located very near (same server f.e.) and the only problem would be invalidating cache entries which still could be achieved with multicast.
The second variant is more complicated and is a good candidate for rmi, imho.'there is still a good chance' is not good enough for me. My experience is that systems that are working 99% are giving a lot of maintainance at that last 1%.
PS. I don't believe it necessary that in all cases all multicast messages should allways be delivered. Consider the following case: an editor saves a news node with related images and urls. A lot gets changed: the news article itself, the description of the image and the editor corrects one of the urls. Because of the nature of the EditWizards Multicast messages of all the nodes involved are being send, only the one of news node gets lost, but relations, other nodes etc get delivered. There is still a good chance that the cached news node gets flushed because it features in one of the cached nodelists, multilelvel caches or whatever :-)
Rob
