On Sunday, Aug 31, 2003, at 04:42 Europe/London, Jan Bartel wrote:
Richard Monson-Haefel wrote:The JNDI ENC is totally static at runtime (per deployment) and therefore a very simple, and fast, in-memeory caching strategy works best.Yes, as far as the ejb deployment unit is concerned, it's java ENC is immutable (although this might be mutable by, eg, the ejb container).
I know, but to have a mutable and immutable view then the JNDI must be mutable at some level.
Will your impl support this type of caching? In OpenEJB, the JNDI ENC impl caches lookups in a HashMap so that subsequent lookups using the same JNDI name are wicked fast – fast as a Hashtable lookup on a small data set. I know that we can use the advanced features of LDAPd in many areas of Geronimo (security, configuration, etc.) but for the JNDI ENC, I think it would be best if we used something lighter. Perhaps, you can provide a caching impl for static data sets like this? The thing is, in most deployments, the number of items stored in the JNDI ENC for a particular component is very small. Speed is of the essence – you can’t get much faster than a HashMap. ;-)
Just to lend further weight to the in-memory vs external storage java:comp/env namespace, the experience over at JBoss was that stress testing showed up that just thread sychronisation on the context environment Properties used by NamingParsers was a significant performance bottleneck. Therefore the throughput could only get worse if we added an external storage mechansism to the lookup process.
I can imagine that an in-memory cache is going to be faster than an external process, but this is an example of way-too-early optimisation. How many times does the JNDI server get consulted? Probably only when the application starts up -- most apps cache Home/DataSource instances anyway, so the speed of lookup is in no way going to be a bottleneck to the runtime part of the system.
There's no point in optimising unless it can be shown that (a) it is in the bottleneck and (b) that X has a clear advantage over Y. For example, it may be that the execution speed of lookup is actually unimportant whereas the amount of memory committed to cache is very important. And given that apps will cache values from JNDI (most of the time) then the cache will become essentially a dual-copy of the memory.
Let's look at lots of ideas, and avoid 'because it is slower' arguments until we can actually show that this is the case.
Alex.
