\On Sunday, August 31, 2003, at 06:42 AM, Alex Blewitt wrote:
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.
Alex go read the code. What we have right now is an immutable context that you bind into you existing JNDI implementation... so we have a node that can be put into *any* tree. The base tree must be mutable so we can bind our context, and after that every thing below us in the tree will be read only.
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 there are places that we know are critical to be fast and there are places we know are not important. We know this because most of the committers have written a J2EE server before. In this case we know people do make lots of JNDI look ups, and yes they should cache it but they don't.
Anyway the important feature is not the speed. The important feature is that it is read only, which is required by the spec. Read the code and you will see that our context is simple (although I can think of a few ways to make it easier to construct).
-dain
