Jason, you're right there is one OGNL context per request in struts, but at the time that the OGNL code was written, concurrency was taken into account, so at this point I think we don't have other choice (there could be other projects that rely on the OGNL thread-safety).
On 6 June 2011 18:24, Jason Pyeron <jpye...@pdinc.us> wrote: >> -----Original Message----- >> From: maurizio.cucchi...@gmail.com >> [mailto:maurizio.cucchi...@gmail.com] On Behalf Of Maurizio Cucchiara >> Sent: Monday, June 06, 2011 12:14 >> To: Commons Developers List >> Subject: Re: [ognl] internal cache performance improvement >> >> Gary hit the nail on the head, considering that OGNL usually >> runs in a multi-thread environment like struts, concurrency is a must. > > While struts2 is multi-threaded access to a given value stack should be in a > single thread, unless explicitly threaded by custom code of the OP. > >> At first glance LRUMap would seem the appropriate choice (it >> was thought for this purpose), unfortunately LRUMap is not >> thread safe, surely we can wrap using >> Collections#synchronizedMap, but it will always a bottlenecks. >> >> On the other hand ConcurrentHashMap seems the appropriate >> choice (Currently the synchronized keyword has 18 match >> inside the OgnlRuntime class). >> >> We could eventually consider to allow the user to decide >> which implementation to choose. >> >> Since I have many complex struts application in production, I >> can do a little test. >> >> >> >> On 6 June 2011 16:55, Gary Gregory <garydgreg...@gmail.com> wrote: >> > Does concurrency need to be taken into account for the >> cache? If so, >> > you need to consider how access to the cache will be >> synchronized. An >> > intrinsic lock? A ConcurrentHashMap? and so on. >> > >> > Gary >> > >> > On Mon, Jun 6, 2011 at 2:36 AM, Simone Tripodi >> <simonetrip...@apache.org>wrote: >> > >> >> Hi all OGNL folks, >> >> my today's topic is about internal cache, that can be IMHO >> improved >> >> in therms of performance; its implementation is a multi-value map >> >> alike, based on a fixed-size array, a function is applied >> to each key >> >> to calculate the array index, each array element is a >> Collection of >> >> element. >> >> Even if getting the list of element related to a general >> key 'k' has >> >> complexity of O(1), which is fine, insert/search >> operations are not >> >> the best because their complexity is O(m) where m is the >> size of list >> >> related to the key. >> >> Follow below my proposal: there's no need to reinvent the >> wheel, so >> >> the array implementation can be replaced with the already provided >> >> HashMap, where each map value is a simple implementation >> of balanced >> >> binary heap (AFAIK commons-collections already provides an >> >> implementation), that allows us reducing insert/search >> complexity to >> >> O(log m). >> >> WDYT? Is is a worth or trivial added value? I know that >> maybe cache >> >> dimension is relatively small, but linear search sounds too basic, >> >> isn't it? >> >> Looking forward to your feedbacks, have a nice day, Simo >> >> >> >> http://people.apache.org/~simonetripodi/ >> >> http://www.99soft.org/ >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> >> >> > >> > >> > -- >> > Thank you, >> > Gary >> > >> > http://garygregory.wordpress.com/ >> > http://garygregory.com/ >> > http://people.apache.org/~ggregory/ >> > http://twitter.com/GaryGregory >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > - - > - Jason Pyeron PD Inc. http://www.pdinc.us - > - Principal Consultant 10 West 24th Street #100 - > - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - > - - > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > This message is copyright PD Inc, subject to license 20080407P00. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
