这里有一个并发问题吗？如何在开发过程中测试它？ [英] Is there a concurrency problem here? How to test it during development?

问题描述

场景：存在'n'个团队，每个人在他们的虚拟墙（如Facebook的墙）上工作。每个团队只看到自己的墙和其上的帖子。帖子可以由帖子的作者或另一个团队成员编辑（如果这样配置，假设这是真的，因为它是必须有的）。

Scenario: There exists 'n' teams who each work on their virtual 'wall' (like facebook's wall). Each team sees only their own wall and the posts on it. The posts can be edited by the author of the post or another team member (if so configured. Assuming this is indeed the case since it's a must have).

设计/技术决策：RESTful Web应用程序使用Restlet + Glassfish / Java + Mysql（编辑：使用Apache DBUtils进行数据库访问，没有ORM - 似乎是一个过分）

Design/technology decisions: RESTful web-app using Restlet+ Glassfish/Java + Mysql ( Using Apache DBUtils for DB access. No ORM - seemed an overkill)

问题：登录T1，T2和T3（说）每个有一些数量的成员。在团队级数据访问时存在并发，但不是跨团队 - 即不同的团队访问不相交的数据集。为了优化从/到DB的频繁读/写，我们考虑了一个TeamGateway，它控制对DB的访问以处理并发。

Question: Multiple teams log on T1, T2 and T3 (say) each with some number of members. There is concurrency at the team-level data access, but not across teams - i.e., different teams access disjoint data sets. To optimize frequent read/writes from/to the DB we are considering a TeamGateway that controls access to DB for handling concurrency. The web-server would cache the data retrieved by the teams to speed up reads (and also to help updating the list of wall posts)

• 网络服务器会缓存小组检索的数据以加快读取速度Q1：这是（每个团队+缓存的TableGateway）甚至需要？


• 如果是这样，TableGateway（每个团队）是否需要编码为线程安全（同步方法）？让我们假设我们有一个类/注册表TableGatewayFinder与一个静态方法，返回TableGateway用于特定的团队（使用hashmap）。

如果每个T1 - T3登录6个人，那么将只创建3个TableGateways，并且它将帮助捕获并发写入（提交前的简单时间戳比较或冲突标记追加），并有效地管理缓存（我们计划具有用于实体的身份映射 - 有4-5个不同的实体需要被跟踪。4个实体用于组合层次结构，另一个实体与每个实体相关联。4）

If 6 people from each of T1 - T3 log on then would ONLY 3 TableGateways be created and would it help catch concurrent writes (simple timestamp comparison before committing or a "conflict-flagged" append) and effectively manage the caching (We plan on having identity maps for the entities - there are 4-5 different entities that need to be tracked. 4 entities for a composition hierarchy and another one is associated to each of the 4)?

一个单元如何测试网关（基于TDD或事后）？

How would one unit test the gateway (TDD based or after the fact)?

提前感谢！

推荐答案

DB或缓存解决方案（例如Spring + Hibernate + EhCache等），你不需要担心损坏你的表等。从低级别的角度来看没有并发问题。

If you just write to the DB or to a cache solution on top the DB (e.g. Spring+Hibernate+EhCache etc.), you don't need to worry about corrupting your tables etc. I.e. no concurrency issue from a low-level point of view.

如果你想自己写一个缓存，并且自己处理并发问题，那么这将需要一些努力。如果你分割你的缓存，并在每个分区有一个全局锁（例如在共同的互斥体上 synchronized ），并获得这个锁，任何访问都可以工作，而它不是最高效的方式做到。但是做一个别的东西而不是全局锁将涉及相当多的工作。

If you want to write a cache yourself and deal with concurrency issues yourself, then that would involve some effort. If you shard your cache and have a "global lock" (i.e. synchronized on a common mutex) per partition, and acquire this lock for any access then that would work, while it's not the most performant way to do it. But doing something else than a global lock would involve quite a lot of work.

虽然这很简单，但不知道为什么要使用标识哈希映射...我不能想到任何特定的原因， （如果你正在考虑性能，那么正常的哈希映射的性能将是你在这种情况下需要担心的最后一件事情。）

While this is trivial, not sure why you'd want to use a identity hash map... I can't think of any particular reason you want to do that (if you are thinking about performance, then performance of a normal hash map would be the last thing you need to be worried about in this situation!).

如果你的实体是文章，那么你可能有另一种形式的并发问题。像由SVN，Mercurial等版本控制软件解决的问题。如果你不把合并的能力，你的应用程序，如果有人编辑某人的文章只是为了发现其他人已经承诺另一个编辑之前你变得麻烦。是否需要添加这样的功能将取决于使用案件。

If your entities are articles, then you probably have another form of concurrency issue. Like the one that is solved by version controlling software like SVN, Mercurial etc. I.e. if you don't put merging capability to your app., it becomes an annoyance if somebody edits somebody's article only to find that somebody else has "committed" another edit before you etc. Whether you need to add such capability would depend on the use case.

至于测试您的应用程式。对于并发，单元测试也不错。通过编写并发单元测试，更容易捕获并发错误。编写并发测试非常困难，因此我建议您在编写它们之前，先阅读一些好的书籍，例如Java Concurrency in Practice。在集成测试之前更好地捕获并发性错误，当它变得很难猜到它是怎么回事！

As for testing your app. for concurrency, unit testing is not bad. By writing concurrent unit-tests, it is much more easy to catch concurrency bugs. Writing concurrent tests is very tough, so I recommend that you go through good books like "Java Concurrency in Practice" before writing them. Better catch your concurrency bugs before integration testing when it becomes hard to guess what the hell is going on!

UPDATE：

@ Nupul：这是一个很难回答的问题。但是，如果你只有18个人打字的东西，我的赌注是写每次到DB都会很好。

UPDATE:
@Nupul: That's a difficult question to answer. However,if you just have 18 humans typing stuff, my bet is writing every time to the DB would be just fine.

如果你不在别处存储任何状态（即只在DB中），你应该去掉任何不必要的互斥体（你不应该在任何其他地方存储任何状态比DB，除非你有非常好的理由这样做在您的情况IMO）。

If you don't store any state elsewhere (i.e. only in the DB), you should get rid of any unnecessary mutex (and you should not store any state anywhere else than the DB unless you have very good reason to do so in your situation IMO).

在做类似网络操作的事情时很容易犯错误并获取互斥量，因此导致极端的可用性问题（例如，应用程序在许多秒钟内没有响应等） 。而且它也很容易有麻烦的并发错误，如线程死锁等。

It's easy to make a mistake and acquire a mutex while doing something like a network operation and hence cause extreme usability issues (e.g. app does not respond for many seconds etc.). And it's also easy to have nasty concurrency bugs like thread dead-locks etc.

所以我的建议是保持你的应用程序。无状态，只是每次写入DB。如果您发现任何性能问题，由于DB访问，然后转向缓存解决方案像EhCache是​​最好的赌注。

So my recommendation would be to keep your app. stateless and just write to the DB every time. Should you find any performance issues due to DB access, then turning to cache solutions like EhCache would be the best bet.

除非你想从项目中学习或者要交付应用程序。对于极端的性能要求，我不认为写自己的缓存层将是正当的。

Unless you want to learn from the project or have to deliver an app. with extreme performance requirement, I don't think writing your own cache layer will be justified.

这篇关于这里有一个并发问题吗？如何在开发过程中测试它？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！