PEAA读后感之Currency（一）

最近在看Martin Fowler的"Pattern of Enterprise Application Architecture"，阅读到Concurrency（并发）一章，看到Flower对并发这个软件设计难点问题信手拈来，举重若情，十分的羡慕。羡慕之余，害怕自己糟糕的记性在看过之后，对这么精华的东西存留不多。故做一次笔记温故知新一番。顺便表达对大师的敬仰之情。

一、并发在企业级软件开发中的位置。
并发在软件开发一贯就是一个难点问题，不仅难于设计，开发，即使软件开发后存在并发问题，也非常难于测试出来（我就看到过测试部门几个人喊一二三测同一个Concurrency TestCase）。
既然是一个难点，我们首先有必要弄清并发是如何产生的:“Whenever you have multiple processes or threads manipulating the same data,you run into concurrency problems”。ok，这个概念简单明了无需多说。更重要的是，好像很熟呦。乎乎，恭喜你，你的记性真不赖，数据库的基本课程就会教这些东西，而且还提供了解决方案：Transaction。那么是否意味着我们在企业级软件开发中就可以把所有的并发问题推给数据库，用Transaction来解决，实际上很多情况是能这样处理的，特别是哪些业务要求不复杂的软件。but现实世界没有这么简单，在企业级软件开发中，首先遇到的问题很多系统间的交互不能最终转化为一个Database Transaction。比如说一个requirement是当一个Market Group超过10人的时候,可以升格为Martet Temm，可以做一些Team才能做的事。很显然，增加人的时候是一个数据库的事务，增加team做的事也是一个数据库事务，这两个事务有内在的联系，需要用一个Business Transaction来管理。
其次，并发虽然重要，但是并不是有并发问题存在的地方，就需要一定要解决。一个原则是：假如你能容忍并发问题，那么你就可以避免处理任何的并发问题（虽然这种情况很少发生）。