我正在从事一个项目，该项目正在从概念验证过渡到值得试点项目的东西。这一开发阶段的关键改进之一是从当前的“持久性”机制（使用保存在内存中并定期转储到文件中的哈希表）转向更传统的数据库后端。
应用程序本身的设计考虑了ReSTful原则。它使用 Jersey 提供对资源的访问，使用 jQuery 向用户呈现这些资源并启用基本交互（创建、更新、删除）。很直接。
我过去曾成功使用 JPA 和 Hibernate 将服务器端状态持久保存在关系数据库中，因此在这种情况下，这似乎是一个自然的选择。通过对模型实体进行一些小的更改，我能够在合理的时间内完成基本的读取、创建和删除操作。然而，更新操作被证明更加困难。
在用户修改资源几秒钟后，应用程序的客户端部分会自动将更改发送到服务器。此外，还有一个“保存并关闭”按钮，用户可以在返回主页之前立即将最新版本的资源发送到服务器。
我的第一个问题是如何使用来自客户端的非托管对象更新数据库中的托管实体。由于发送到客户端的数据故意省略了数据库键，这有点乏味，因为它归结为将非托管对象中的元素显式“合并”到 Hibernate 对象中。这不是我的问题，但如果有人知道一种优雅的方式来做到这一点，我很想听听。
我的第二个问题，也是这篇文章的目标，发生在我按下“保存并关闭”按钮的同时，我之前提到的自动保存操作正在进行。通常，我得到一个乐观锁定异常。这是因为第二个更新操作正在一个单独的线程中处理，而第一个更新操作仍在处理中。
该资源具有每次处理更新时设置的“更新”时间戳，因此每次都可以保证对数据库的更新，即使没有任何更改。这本身可能是一个问题，但即使在我修复它之后，仍然有一个“机会之窗”，用户可以在自动保存过程中进行修改并将其发送到服务器，从而触发同样的问题.
我能想到的解决此问题的最简单方法是重新编写一些客户端 Javascript，以确保该客户端在任何时间点都只有一个未完成的“更新”操作。（请注意，如果不同的客户端碰巧同时更新相同的资源，乐观锁定异常是完全可以的。）但是，我担心在客户端上强制执行此限制可能会偏离 ReST 的精神。期望给定客户端在 ReSTful 应用程序中的任何时间点对特定资源的未完成“更新”（PUT）请求不超过一个是否合理？
这似乎是一个相当普遍的情况，但我无法找到关于如何最好地处理它的明确答案。我考虑和放弃的其他想法包括以某种方式序列化来自同一客户端的请求（可能基于 HTTP 会话），以便按顺序处理它们，为 JPA/Hibernate 工作线程实现更新“队列”，并插入新的“版本”的资源，同时跟踪最新的而不是更新任何单个记录。
有什么想法吗？客户端的“一次一个未完成的更新”限制是否合理，还是有更好的方法？