It appears (in recent podcasts) that the Posse (Dick only?) equates multi-threading to parallelism. Definitely, if you're interested in calculations and batch processing this is the way to go and Actors/MapReduce/Executors/Futures/fork-join/ etc. help greatly.
Concurrency seems to be ignored though... Bruce Eckel brought it up a little (Goetz talk?) but the discussion moved quickly to parallelism (and Scala...). :-( Typically, applications that rely on a lot of interactions and shared data can't use these high level constructs. The current solution is to use a container (app-server?) to deal with the interaction part and hope for some data access layer to deal with the shared data issues. But this breaks down very quickly when performance isn't good. Then these tasks are moved in the application itself and we're back to square one again... So far, I haven't seen many answers to this. The only answer I've found is the excellent MultithreadedTC by Bill Pugh and Nat Ayewah. It is a very good tool but still relies on already understanding the multi-threading issues that you are testing for... If you don't it's a bit of a chicken-and-egg problem... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
