复制或保存冲突是LotusNotes的一大独特问题。这些冲突之所以会产生，就在于Notes数据库最基本的设计之一就是副本独立读写，再通过复制保持数据一致。此外不像关系型数据库优先数据的一致性，读取要被改动的记录时会锁定这些记录，阻止同时有其他写入。Lotus Notes的文档锁定功能直到R6才被引入，并且仍然由于Notes数据库的分布式本质，应用并不广泛。
既然易于出现，我们这要好好地了解它们，以尽量减少这些麻烦。
原因
我们先来看保存冲突，因为它不必有副本就可能产生，比复制冲突更广泛。Lotus Notes帮助文档中对保存冲突的描述略有误导之嫌。
A save conflict occurs when two or moreusers open and edit the same document at the same time on the same server, evenif they're editing different fields.
很多资料提到保存冲突产生的原因时，还会说是因为同时保存同一个文档，就更令人迷惑了。何谓同时？Notes数据库能并行地处理多个保存同一个文档的请求吗？文档在物理存储中总是唯一的，如何同时保存？同时的标准又是什么？时间上相差0.1秒算吗，还是0.1毫秒，0.1微秒？如果还是串行地先后保存，会产生冲突吗？
实际上，要了解这个保存冲突产生的原因，正可以借鉴复制冲突的原因。两个副本中的同一文档都被修改，再被复制的时候，肯定就会产生冲突，这很好理解。保存冲突其实也是同样的道理，某个文档被读取并修改，在这些变化被写回数据库之前，这个文档又被同一用户或其他用户（不必像帮助文档所写，限于两个或以上不同用户的情况，单个用户也可能产生冲突文档）读取，或有或无修改，再保存。这两次保存时间上较晚的一次就会产生冲突。不论这两次从读取到保存的会话的先后顺序如何，只要它们时间上有重叠，冲突的问题就产生了。或者从机制上说，当内存中的文档要被写回磁盘里对应的文档时，如果发现此时后者与前者被读取时的内容不同，也就是后者的最近修改时间不再是前者被读取时的最近修改时间，就意味着这个文档有了两个不同的版本。
冲突产生后，一个版本被选为主文档，其它则成为它的冲突文档。冲突文档会被添加两个域，一个$Conflict表明是冲突文档，另一个与普通响应文档相同的$Ref域记录主文档的全局Id。
情境
在客户端应用中，如果一个表单触发的代码会通过某种间接的方式修改保存当前文档（不是直接地通过NotesUIWorkspace.CurrentDocument的方式，而是比如经由某个视图修改的文档包括当前文档），然后用户再直接修改保存当前文档，就会产生冲突。与此相对的是，即使一个数据库没有选中锁定文档的选项，在客户端中如果有一个用户甲正在编辑某个文档，其他用户在试图编辑同一数据库副本里的该文档时，也会收到Lotus Notes的提示，甲正在编辑该文档，因此只能阅读不能编辑。
在传统的Notes Web应用中，用户如果快速点击提交保存一个文档的按钮，也可能产生该文档的保存冲突。
应对措施
了解了保存冲突产生的原因，就可以在开发中尽量避免。除非在某些特殊场合，在调用文档的保存方法NotesDocument.Save()时，都会使用不创建冲突文档的参数选项。对于产生原因仍然不明的冲突文档，我们也需要有措施应对。可以建立一个选择条件为
SELECT @IsAvailable($Conflict)
的视图，有需要或不定时地检查是否有新的冲突文档。有些人会写一段脚本自动清除这些冲突文档。笔者比较谨慎，会先人工对比一下冲突文档和主文档有什么不同，再看看能不能找到产生的原因，之后再做相应的处理。为了比较，也可以写一段代码检查两者有哪些域的内容不同。
在下一片文章里，我们会讨论一下另一种冲突文档——复制冲突。看看Lotus Notes是怎样创建和处理它们的，隐秘的域级别的冲突检查，以及一点理论上的探讨。