多个事务并发写相同对象时，会出现脏写和更新丢失两种竞争条件。为避免数据不一致，可：
但这还不算并发写可能引发的全部问题。
为医院写一个值班管理程序。医院通常会同时要求几个医生待命，前提是至少有一位医生在待命。医生可以放弃他们的班次（例如，如果他们自己生病了），只要至少有一个同事在这一班中继续工作。
Alice、Bob两位值班医生都不适，所以他们都决定请假。但他们恰在同一时刻点击调班按钮
每笔事务总先检查是否至少有两名医生目前在值班。若是，则有一名医生可安全离开去休班。由于DB使用快照隔离，两次检查都返回2 ，所以两个事务都进入下一阶段。Alice更新自己的记录为休班，Bob也更新自己的记录。两个事务都成功提交，最后结果没有医生值班，显然违反至少有一名医生值班的业务要求。
这种异常称为写倾斜，不是脏写，也不是丢失更新，这俩事务更新的是两个不同对象（Alice 和 Bob 各自值班记录）。这里发生的冲突不是那么明显，但很显然确实是竞争状态：若两个事务串行，则第二个医生就不能歇班。异常行为只有在事务并发时才可能。
可将写倾斜视为广义的丢失更新。即若两事务读取相同一组对象，然后更新其中一部分：
我们有很多方法防止丢失更新。但对写倾斜，方案更受限制：
写倾斜乍看晦涩，但意识到本质后，很容易注意到更多case：
所有这些案例都遵循类似模式：
上述步骤可能有不同执行顺序。如可先写，然后SELECT查询，最后根据查询结果决定是放弃还是提交。
医生值班案例，步骤3所修改的行恰好是步骤1查询结果的一部分，所以若通过锁定步骤 1 中的行（SELECT FOR UPDATE）再查询可保证事务安全，避免写倾斜。但其他四个案例不同：它们检查是否 不存在 某些满足条件的行，写入会 添加 一个匹配相同条件的行。若步骤1中的查询没有返回任何行，则 SELECT FOR UPDATE 锁不了任何东西。
这种效应：一个事务中的写入改变另一个事务的搜索查询结果，即幻读。快照隔离避免了只读查询中的幻读，但是在像我们讨论的例子那样的读写事务中，幻读会导致特别棘手的写倾斜。
若幻读的问题是没有对象可以加锁，也许可以考虑人为在DB引入一个锁对象？
现在，要创建预订的事务可以锁定（SELECT FOR UPDATE）表中与所需房间和时间段对应的行。锁定后，它可检查重叠预订并像以前一样插入新预订。该表不是用来存储预订相关信息的，它完全就是一组锁，以防止同时修改同一房间和时间范围内的预订。
这被称为物化冲突（materializing conflicts）方案，因为它将幻读变为DB中一组具体行上的锁冲突。但弄清楚如何物化冲突很难，也很易出错，而让并发控制机制泄漏到应用数据模型是很丑陋的做法。出于这些原因，若无其他办法可以实现，物化冲突应被视为最后手段。大多数情况下，可串行化（Serializable） 隔离级别更可取。