迭代器和并发策略

Question

评估不同的服务器解决方案时，我需要了解Play2如何处理使用迭代器时的并发性，特别是处理Websockets请求时。

如果你看一下这个代码显示共享状态的简单的WebSocket服务器（A协作涂料应用）https://github.com/gre/playpainter/blob/master/scala/app/controllers/Application.scala

你会看到每个网页套接字请求可以潜在地修改共享状态，如画家绘制或连接计数器。这段代码是否线程安全？如果是的话（作者证实）Play2在内部处理并发性如何？在这一点上，我没有Scala级别来不幸地完全理解play2 lib代码。

我想知道他们如何能调解线程安全（地图或柜台只能由一个线程在同一时间修改）高性能（可将多个请求“同时”处理。

唯一我可以想到的是他们将每个迭代块的处理包装在它自己的线程事务中;这最终严重限制了并发性（尽管简化了用户代码）并且最终得到类似于Node.js或任何单线程服务器将提供的性能？我可以看到Iteratee编程模型在流式处理，文件处理等方面的好处，但对于每个请求触发非平凡工作（Web服务器计算，数据库访问等）的websocket来说，并没有太多好处。

Answer 1

我错了我的应用程序的线程安全性，它有一个错误。

我刚刚修复它利用ConcurrentHashMap中，看到的变化https://github.com/gre/playpainter/commit/5120de5b77627836fe26602546f82c99a28cdf1b

感谢您的报告。