乐观并发控制：

同样假设A和B需要在SCC上修改同一个文件，他们都将这个文件获取到自己的机器上，A修改完以后，就把文件上传到SCC上了，此时B也修改完了，当他也打算将文件上传时，系统会告知B，已经有人上传了，并出现一个错误。剩下的问题只能由B手动解决，例如B可以在SCC上将文件中更改的内容再次复制一遍。乐观并发控制使得系统效率损耗在事务的后期处理中，比如B必须手动的去修改他已经修改过的东西，然而这种控制方式在极少出现冲突的多事务处理中显得十分高效。

悲观并发控制：

假设A和B需要在SCC（Source Code Control）上修改同一个文件，那么在A锁定这个文件并修改的过程中，B无法修改这个文件，他只能等待A解锁文件后，他才能修改。由此可见，悲观并发控制是强调控制在前，确保整个过程不会出现文件版本的冲突。这样做会使得系统效率损耗在加锁机制上，尤其是加锁机制需要用到低速的外部存储（比如FileLocking）时，然而这样做就降低了事务的并发性，尤其是事务之间本来就不存在冲突的情况下。例如在A修改数据的时候，B只能等待。

乐观并发控制将事务分为三个阶段：读取阶段、校验阶段以及写入阶段。在读取阶段，事务将数据写入本地缓冲（如上所述，A和B将文件都获取到自己的机器上），此时不会有任何校验操作；在校验阶段，系统会对所有的事务进行同步校验（比如在A或者B打算，但还没有，往SCC上写入更改后的文件时）；在写入阶段，数据将被最终提交。在完成读取阶段以后，系统会对每个事务分派一个时间戳。

悲观并发控制中一个常见的问题就是死锁。例如A在修改文件T1，B在修改文件T2，他们分别锁定了这两个文件，假设T1和T2内容相关，B在修改T2的时候发现他还需要修改T1，可是T1却被A锁定；与此同时，A在修改T1的时候也发现了他还需要修改T2，可是T2又被B锁定了，这样就出现了死锁。当然，在实际操作中，这种情况可以由A和B协商解决，但是在错综复杂的多事务处理环境中，死锁将使得问题变得非常复杂。