在使用load获得的实体上使用lockLockModeType.OPTIMISTIC_FORCE_INCREMENT是否有效？

我正在处理一个批量数据加载框架，该框架使用load(...)获取对我们已知存在的实体的引用，这些实体将用作要创建的实体的父对象（必须为这些新子对象设置）多对一属性）。永远不会对父项进行任何其他更改。它本质上是不可变的后创建。

这样做是为了减少获取并优化性能。除其他事项外，框架引擎非常仔细地执行操作，以启用大型，连续的JDBC批处理。在大多数情况下（几乎接近100％），这些“父项”将不会在同一会话中获取或创建，因此，据我所知，load(...)的结果将是一种空壳

为促进正确的乐观锁定，每次获得新的子代（或删除子代）时，都需要增加父代的版本。这可以使用lock(parent,LockModeType.OPTIMISTIC_FORCE_INCREMENT)方法来完成。在这种情况下，我想了解实际上/需要在这里发生什么。

将需要读取/获取父版本，以方便以后进行比较。但是，这可能比实际获取父对象便宜和乐观。想到的一些事情是，Hibernate可以批量读取许多版本，而不是一个一个地加载它们，甚至比实际获取的父实体更有效地存储/处理它们。以后的比较和增量也可以类似地优化。这有很多“可能”……但是会发生什么呢？

是否会因为实体是来自load（）的空外壳而使Hibernate出错？还是...
是否会执行昂贵的获取操作，并且要获取默认的映射指定属性（不幸的是，此处未对其进行优化，这太可怕了）？
否则，对lock（）的重复调用有多昂贵？我是否应该对其进行保护，以便最多调用一次，并且难道不是每个成千上万的孩子都被添加到同一个父母中？如果父级也发生变化，是否会产生副作用（我知道我没有说过，但是在极少数情况下可能会发生这种情况，并且父级可能在同一事务中创建）。

有人可以澄清吗？谢谢！