java - Wicket 口、身份验证和交易界定

Question

我将 Wicket 与自定义 PageAuthorizationStrategy 结合使用，该策略访问数据库以获取有关当前用户及其访问权限的信息。每个请求都由 Spring Open-Session-In-View 过滤器包装以打开/关闭 Hibernate session 。

这非常适合对数据库的读取访问。每当需要进行写入操作时，我都会调用使用 Spring 基于注释的事务处理的服务层。这也有效，但我认为这是导致特定错误的原因:当在请求 A 中的身份验证期间加载对象，然后在另一个请求 B 中修改，然后在请求 A 中移交给服务层时，服务层正在处理错误的值，因为 Hibernate 和底层数据库都无法确保隔离。由于我总是在数据库/事务理论的细节上遇到一些困难，如果这个假设已经错误，请纠正我。

我的解决方案的第一个想法是在写入事务开始后立即刷新加载的对象以进行身份​​验证。但是，当服务要修改的对象同时需要进行身份验证时，这会导致问题。当 Wicket 使用表单中更改的数据填充对象并将其传递到提交方法中的服务时(例如)，尤其会发生这种情况。

因此，正确的方法可能是确保身份验证代码已经包装在与同一请求期间可能执行的任何写入代码相同的事务中。

我将如何在 Wicket 中以“正确的方式”解决这个问题？

编辑:这个问题变得更加严重，因为我意识到当事务服务方法在抛出异常后回滚时， View 层会导致 LazyInitializationException。显然，Spring 的 TransactionManager 会清除 session 和/或 Hibernate/Spring 深处的其他内容出错，因为我可以从数据库重新加载对象，但尝试加载该对象中包含的集合会导致所述异常。有什么想法如何解决这个问题吗？我想如果有一种优雅的方式来使用“每个请求一个事务”，那么这一切都会得到解决。

Answer 1

这不是 Wicket 问题，而是 DB/Hibernate 问题。 Hibernate有support适用于乐观和悲观策略。

optimistic approach包括向实体添加一个 version 字段，该字段将在刷新更新时进行验证，如果记录已被某人修改，则会引发异常。

pessimistic approach使用数据库支持锁定记录，避免并发修改。

两者都有优点和缺点，并且都需要您积极使用相应的功能和代码才能使其工作(没有魔法灰尘)。

乐观者必须处理任何可能出现的异常。

悲观主义者将不得不处理争用和可扩展性问题。

乐观者可能必须更改模式结构和/或域模型来处理某些情况。

悲观主义者在处理该表的更新时必须始终担心锁定(您忘记在一个地方锁定，并且您刚刚创建了 heisenbug )。

NoSQL 人员会告诉他们完全放弃关系数据库，在没有模式、事务和一致性的情况下快乐地生活(顺便说一句，这在大多数情况下是愚蠢的)。