如何确保休眠版本号在 javascript 客户端中保持不变?
我有一个带有 Java 和 Hibernate 的 Rest 后端，并且我使用带有 version 属性的 Optimistic Locking.对于并发控制，此版本属性必须通过 post 请求发送到客户端并再次发送到服务器.但是，在 javascript 客户端中，我无法控制此属性的完整性，例如:
I have a Rest backend with Java and Hibernate and im using Optimistic Locking with the version property. For concurrency control, this version property must go to the client and again to the server with post request. But, in a javascript client i lose control over the integrity of this property, for example:
- 客户端A"请求资源 1.
- 客户端B"请求相同的资源.
- 服务器使用资源 1 版本 1 响应两个客户端(在它们各自的响应中)
- 客户端A"修改资源并发布帖子以保存更改.
- 服务器处理 post 请求，Hibernate 检查版本号.1 = 1，因此资源被修改.
- 客户端B玩javascript，修改version属性为2，发出post请求.服务器处理 post 请求，现在 2 = 2，因此资源被修改，客户端 A 所做的更改丢失.
请记住，这是一个 Rest 后端，因此我无法在服务器中保存交付给每个用户的对象的版本号，或者类似的东西.
Remember that is a Rest backend, therefore i can't save in the server the version number of the objects that were delivered to each user, o something like that.
那么，如果我认为这是一个有效的问题，我如何确保版本在客户端中保持不变?
So, if this is a valid question like i think it is, how can i ensure that the version stays immutable in the client?
推荐答案
就个人而言，我会重新考虑这样做，因为我看不到客户这样做的动机，而且根据定义，您无法控制客户发送的内容您的 REST 服务.
Personally, I would rethink doing this, as I see little to no motivations for a client to do that and by definition you can NOT control what a client sends to your REST service.
但是，如果您确实有业务案例，那么一种半解决方案是将版本属性设为 GUID.这样，您只能在您拥有最新的 GUID 时提交，而客户端 B 没有该 GUID，并且它使版本控制情况更加复杂，因为在请求成功之前您不能只增加 1.
However, if you really do have a business case, then one semi-solution is to make the version property a GUID. That way, you can only submit if you have the newest GUID, which client B would not have, and it makes the versioning case more complicated because you cannot just increment by 1 until the request succeeds.
但是，即使在那里您也不是完全安全的，因为理论上客户端 B 可以单独请求从资源中获取更新的 GUID，然后使用更新的 GUID 重新提交失败的请求.
However, even there you are not entirely safe, as client B could theoretically do a separate request to get the updated GUID from the resource and then resubmit the failed request with the updated GUID.
但是由于客户端 B 可以对更新版本进行编辑以恢复客户端 A 所做的并添加他们自己的，这与这样做本质上是相同的，并且由于他们有权这样做，所以我们重新询问我们自己为什么要再次担心那个案子.
But since client B could have done an edit on the updated version to revert what client A did and add their own, this is essentially the same as doing that, and since they have authority to do that, we are back to asking ourselves why we are worrying about that case in the first place again.
相关文章