Thanks, but I don't want to use a cache library (yet), because I want to get my own hands dirty.
Joined: Mar 22, 2005
In that case, what do you have so far, and where are you stuck making progress?
Joined: Jun 19, 2008
For now i have off course the application itself :-), and a simple cache which consist of a class which holds a reference to a map which is periodically being replaced by a new instance of a map which has been populated by the same task. Why ever time creating a new map and replacing the old one?
Because at the moment this seems the easiest way for me to avoid the dreaded race conditions without locking the whole current map in use because updating from ldap takes a long time about 15 seconds.
I guess this can be done better without using every time a new map. If this works fine I also want to add, updating individual records/objects by adding the ldap notification support, which off course adds more complexity.
I'm not afraid that their will be memory leakage due to the fact that their are still references to the old map, because all references exist only for the duration of a request.
So writes should only come from the ldap notification event handlers and from the task which updates the whole map. And reads from the rest of the application. Reads can come from individual look up of entries are from looping through all map entries.
I all ready know that you have all kind of map implementations which have been optimized for concurrent use, but I also know that you have to be very careful and know exactly what you are doing, otherwise things can go terribly wrong.