PureMVC Architects Lounge

Hi, I'm wondering why this port doesnt use ConcurrentHashMaps instead of HashMap+synchronized block?

for example in the Facade.getInstance method, its synchronized which has gotta be bad for performance
since its a commonly accessed method.
also, why does it bother to generate a "new Facade(key)" if one isnt provided? if it hasnt been subclassed then the app cant be using puremvc as its intended, and if it has been subclassed then creating this new Facade is a waste of effort.

at any rate to keep existing functionality, wouldn't replacing the instanceMap with a concurrenthashmap and reworking the method something like this make sense?
   
public static Facade getInstance(String key )
if (key== null) {
            throw new Exception("key cannot be null.");
        }

 Facade facade, newVal;
    do {
      facade= instanceMap.get(name);
      newVal = (facade== null) ? new Facade(key):facade;
    } while (!instanceMap.replace(name, facade, newVal));

        return newVal;
    }
}


Cheers

Thanks for pointing this out Jason. Certainly seems like ConcurrentHashMap would be attractive in this situation. However you do have to be extremely careful with its use, it's not as simple as replacing HashMap with ConcurrentHashMap and removing the syncrhonized block. Check out this article on the subject:

http://dmy999.com/article/34/correct-use-of-concurrenthashmap

Anthony, what do you think?
-=Cliff>

http://dmy999.com/article/34/correct-use-of-concurrenthashmap

read to the comments at the bottom of the article. cchashMap is safe and works as intended.
it wont fix other problems in your code though of course.
My point here is that the current version blocks unnecessarily, and is also trying to do something that doesn't make any sense. perhaps it should be restructured such that it really is a factory?

incidentally, methods such as  Facade.removeCore are not threadsafe at all, as they are modifying an unmanaged hashmap.

same applies for the controller, model and view classes too!.

Agreed. Anthony, would you care to look into this?

-=Cliff>

This port doesnt use ConcurrentHashMaps instead of HashMap+synchronized because PureMVC Multicore is GWT compliant.
GWT includes a library that emulates a subset of the Java runtime library and this library doesn't have
java.util.concurrent.ConcurrentHashMap

Thanks Jason, effectively, methods such as Facade.removeCore are not threadsafe and i have to release a new version with correct code.

Anthony.

if the new 'threadsafe' code is blocking though it would be a real shame.
perhaps you need to use the Map interface only, and allow a mechanism for selecting the correct runtime
wiring (GWT, or jvm1.5+) .
alternatively has anyone tried retroweaver for converting modern java bytecode to java 1.4 compat bytecode? ref:http://retroweaver.sourceforge.net (I havent, no idea if it would work)
if it worked you could just add this as a secondary post build target to generate a gwt compatible variant.