2000年，当美国的IT经济最萧条的时候，一个于92年Alabama大学经济与政治学系的毕业生成立了一家叫tangosol的公司。这是一个很奇怪的名称，因为当时已经没有更多的域名了，tango和sol是两个拉丁字母，分别代表”to touch”和”the sun”。这家刚成立的公司当时并不知道他们要开发什么产品，他们只想做Java企业级应用的开发，因为之前他们都是这方面的老手。

Tangosol一开始就是这样一个J2EE的咨询公司。在不停地做咨询过程中，他们不断地发现几乎所有大应用都共用的问题：数据库通常会是大系统的瓶颈，应用服务器和Web层可以很轻松地scale up，而数据库层却并不是那么容易。有一次他们给一家叫做Precise的大公司做咨询 (也许大家都不曾听说过这家公司，但就是它买下了Middleware公司和2002年前的TheServerSide网站)，那家公司的人提出来能不能把数据库里的部分内容放到Cluster的内存中，然后通过某种机制保持内存与Cluster结点上的内容一致。当这么一个大公司提出这样一个大需求时，Tangosol知道这是一个重要的商机，他们的机会来临啦。

于是Tangosol Coherence，这个全世界最贵的HashMap就这样诞生了，高达4999美金一个CPU的HashMap并没有把他们的客户吓跑。这么多年，有无数的客户使用了Tangosol Coherence，使系统的performance, scalability和availability大大提升。他们客户有TheServerSide, JiveSoft，Sony，还有其它无数的大公司。几乎每一个在TheServerSide上玩过Coherence的人都会赞扬它的品质。

前面提到的那位经济与政治学的毕业生就是Cameron Purdy。他是TheServerSide上最活跃的分子之一，无数贴子后面都会看到他的留言。他也是最勤劳而幽默的blogger之一，每个月他的blog上都会有很多新的内容。一个最经典的贴子是他对2005年业界的预测：http://www.theserverside.com/news/thread.tss?thread_id=30938。

Cameron Purdy还有一个特点就是无时无刻不忘为他的昂贵的HashMap做宣传，在每个贴子后面都会有这样的留言：


然而当看到Cameron Purdy的采访和讲座时，觉得他说话时的幽默感没有他写出来的时候那么强烈。虽然是标准的美音，但言语之间似乎缺少一种抑扬顿挫，如果不仔细听很容易睡着。不记得谁在blog上说Cameron Purdy是一个good speaker（好象是Hani Suleiman的BileBlog，他们俩是死党），我始终不觉得，他的表现力远没有Ted Neward强，而Rod Johnson虽然不很幽默，但他说的每个字都会钻进我的耳朵里，然而Cameron Purdy的每句话我都得竖起耳朵听，当然如果仔细听他的讲座会有很多收获。在今年的TheServerSide Symposium上，观众唯一一次集体拍手，是因为Cameron Purdy的老婆刚好生小孩，结果讲到一半想不起来讲啥了，结果观众集体鼓掌鼓励了一下。呵呵，后来听说他生了个女孩。

在Tangosol的网站上，我们还可以找到Cameron Purdy很多讲座的PPT，除了那个经典的Clustered Cache讲座和P2P Cluster讲座之外, Scalability and Performance without Buzzword是最有趣的一个。这是他和SolarMetric的CTO Patrick Linskey（还记得KODO JDO吗？anyway, Patrick Linskey is a good speaker），可惜只有PPT，不知道TheServerSide会不会推出他们的现场讲座，I’m anticipating。

在Cameron Purdy的blog上，我们也会发现好多有趣的事情。他的blog地址是：http://www.jroller.com/page/cpurdy。除了很多技术上的八卦，还会有一些生活上的小事。比如说去溜冰啦，还有波士顿的聚会啦,去某个地方做演讲啦,etc.

Camerson Purdy当目前为止似乎还没写过书，虽然在他的blog上号称要写Effective Enterprise HashMap和Expert One on One J2EE Without HashMap，呵呵！

Cameron Purdy还是JSR107也就是JCache的Specification leader。不过我认为这个标准对我们意义不大。当时是Oracle的那帮家伙做了个Cache系统，想把他变成标准，结果就向JCP提交了。结果做到一会儿，那家伙(好象叫Jerry Bortvedt)对这个失去了兴趣，于是就打电话找Cameron Purdy，那应该是2003年的12吧，于是乎Cameron Purdy就当上了JCache的Specification Leader。但是这么多年过去，JCache仍然没能最终定稿。因为象这样的Cache API是很难制定标准的，Cache的解决方案各式各样，有人喜欢用HashMap，有人喜欢用tree和HashMap结合(JBoss Tree Cache)，也有人喜欢把整个关系数据库做Cache（如TimesTen），凭什么你做一个基于HashMap的标准，就要让大家都用这个标准。呵呵，也许有一天Apache会推出一个Common Cache，我们就不用依赖于某个Cache API了，我们只要依赖于Apache最复杂的API和他相关的十几个包。