Re: [Wicket-develop] resolveClass in DefaultClassResolver

[Igor Vaynberg]

the whole point is NOT to sync if we previously looked up the class, so that parallel threads can read the map, and we only sync when we write into the map. the idea is that once most classes are loaded there is no more sync going on, well, it still happens but it is governed by the locking semantics of the ConcurrentReaderHashMap which should allow parallel readers.

-Igor

On 4/25/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:

you mean line 53? Class clz = (Class)classes.get(classname);

here the map does the sync for us, so need for us to do it.

-Igor

On 4/25/06, Dirk Markert <[EMAIL PROTECTED]> wrote:

I think the problem is the clz variable. It is modified inside the synchronized block and read in a not synchronized part.

2006/4/26, Igor Vaynberg < [EMAIL PROTECTED]>:

we are using a map with concurrency semantics already built into it.

-Igor

On 4/25/06, Dirk Markert < [EMAIL PROTECTED]> wrote:

After reading this article http://www.javaworld.com/jw-02-2001/jw-0209-double.html about the double-checked locking idiom I looked at resolveClass() in DefaultClassResolver. Comparing the example in the article and the resolveClass() method I got the impression that resolveClass() might not work as expected:
The local variable clz might be not null since another thread working in the synchronized block has just created the reference. Yet, the object behind clz might not be fully constructed. The test clz == null will fail returning a not fully initialized object.

Synchronizing the whole method should fix the problem.

Dirk