gpt4 book ai didi

java - 如何拦截 JTA 事务事件并获取对与事务关联的当前 EntityManager 的引用

转载 作者:搜寻专家 更新时间:2023-10-31 20:19:50 31 4
gpt4 key购买 nike

长话短说:我们开发并维护了一个库,该库可用于其他使用 JavaEE7/CDI/JPA 的项目。应用程序将在 Glassfish-4.0 下运行,并使用 Hibernate 的 JPA 实现作为底层 PostgreSQL 持久性。这是一项长期迁移工作的一部分,目的是将用 Spring/Struts/Hibernate 编写的旧应用程序重写到 JavaEE7/CDI/JTA 的新世界中。

问题:出于审计目的,我们的库需要在执行用户语句之前拦截所有数据库事务并包含自定义 SQL 语句。此时,需要将当前用户名和 IP 地址插入临时数据库变量(供应商特定功能),以便数据库触发器可以读取它们,为任何行修改创建审计跟踪。 This particular post was very helpful providing alternatives ,我们的团队由于先前建立的遗产而走上了触发之路。

然而:我们对 JTA 处理事务事件的方式深感感到失望。拦截交易的方法有很多种,但这种特殊情况似乎是完全不可能的。在旧架构中,使用 Spring 的事务管理器,我们简单地使用了一个 Hibernate Interceptor。实现 Interceptor.afterTransactionBegin(...)。阅读 official JTA-1.2 spec ,我们发现它确实支持Synchronization.beforeCompletionSynchronization.afterCompletion。经过几个小时的调试 session 后,我们清楚地注意到 Hibernate 的 JTA 实现正在使用这些工具。但是 JTA 似乎缺少像 beforeBeginafterBegin 这样的事件(恕我直言,这似乎是缺乏常识)。由于没有拦截这些的工具,Hibernate 完全符合 JTA 而它根本不会。期间。

无论我们做什么,我们都找不到办法。例如,我们尝试拦截 @Transactional 注释并在容器的 JTA impl 完成其打开事务的工作后立即运行我们的代码。但是我们缺乏动态获取与该特定事务关联的 EntityManager 的能力。请记住:这是一个库,而不是 Web 应用程序本身。它不能对应用程序声明和使用哪些持久性单元做出任何假设。而且,据我们所知,我们需要知道将哪个特定的持久单元名称注入(inject)到我们的代码中。我们正在努力为其他 temas 提供尽可能透明的审计工具。

所以我们虚心求助。如果有人有解决方案、解决方法或任何意见,我们将很高兴听到。

最佳答案

我自己在这篇文章中很快就回答了这个问题,但隐藏了一个事实,即我们花了两周多的时间尝试不同的策略来克服这个问题。因此,这是我们决定使用的最终实现。

基本思路:通过扩展 Hibernate 提供的实现来创建您自己的 javax.persistence.spi.PersistenceProvider 实现。对于所有效果,这是您的代码将绑定(bind)到 Hibernate 或任何其他供应商特定实现的唯一点。

public class MyHibernatePersistenceProvider extends org.hibernate.jpa.HibernatePersistenceProvider {

@Override
public EntityManagerFactory createContainerEntityManagerFactory(PersistenceUnitInfo info, Map properties) {
return new EntityManagerFactoryWrapper(super.createContainerEntityManagerFactory(info, properties));
}

}

想法是用您自己的实现包装 hibernate 版本的 EntityManagerFactoryEntityManager。因此,您需要创建实现这些接口(interface)的类,并将供应商特定的实现保留在内部。

这是 EntityManagerFactoryWrapper

public class EntityManagerFactoryWrapper implements EntityManagerFactory {

private EntityManagerFactory emf;

public EntityManagerFactoryWrapper(EntityManagerFactory originalEMF) {
emf = originalEMF;
}

public EntityManager createEntityManager() {
return new EntityManagerWrapper(emf.createEntityManager());
}

// Implement all other methods for the interface
// providing a callback to the original emf.

EntityManagerWrapper 是我们的拦截点。您将需要实现接口(interface)中的所有方法。在每个可以修改实体的方法中,我们都包含对自定义查询的调用以在数据库中设置局部变量。

public class EntityManagerWrapper implements EntityManager {

private EntityManager em;
private Principal principal;

public EntityManagerWrapper(EntityManager originalEM) {
em = originalEM;
}

public void setAuditVariables() {
String userid = getUserId();
String ipaddr = getUserAddr();
String sql = "SET LOCAL application.userid='"+userid+"'; SET LOCAL application.ipaddr='"+ipaddr+"'";
em.createNativeQuery(sql).executeUpdate();
}

protected String getUserAddr() {
HttpServletRequest httprequest = CDIBeanUtils.getBean(HttpServletRequest.class);
String ipaddr = "";
if ( httprequest != null ) {
ipaddr = httprequest.getRemoteAddr();
}
return ipaddr;
}

protected String getUserId() {
String userid = "";
// Try to look up a contextual reference
if ( principal == null ) {
principal = CDIBeanUtils.getBean(Principal.class);
}

// Try to assert it from CAS authentication
if (principal == null || "anonymous".equalsIgnoreCase(principal.getName())) {
if (AssertionHolder.getAssertion() != null) {
principal = AssertionHolder.getAssertion().getPrincipal();
}
}
if ( principal != null ) {
userid = principal.getName();
}
return userid;
}

@Override
public void persist(Object entity) {
if ( em.isJoinedToTransaction() ) {
setAuditVariables();
}
em.persist(entity);
}

@Override
public <T> T merge(T entity) {
if ( em.isJoinedToTransaction() ) {
setAuditVariables();
}
return em.merge(entity);
}

@Override
public void remove(Object entity) {
if ( em.isJoinedToTransaction() ) {
setAuditVariables();
}
em.remove(entity);
}

// Keep implementing all methods that can change
// entities so you can setAuditVariables() before
// the changes are applied.
@Override
public void createNamedQuery(.....

缺点: 拦截查询 (SET LOCAL) 可能会在单个事务中运行多次,特别是在单个服务调用中有多个语句的情况下。在这种情况下,我们决定保持这种方式,因为它是对 PostgreSQL 的内存调用中的简单 SET LOCAL。由于不涉及表,我们可以忍受性能下降。

现在只需在 persistence.xml 中替换 Hibernate 的持久性提供程序:

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"
version="2.1">
<persistence-unit name="petstore" transaction-type="JTA">
<provider>my.package.HibernatePersistenceProvider</provider>
<jta-data-source>java:app/jdbc/exemplo</jta-data-source>
<properties>
<property name="hibernate.transaction.jta.platform" value="org.hibernate.service.jta.platform.internal.SunOneJtaPlatform" />
<property name="hibernate.dialect" value="org.hibernate.dialect.PostgreSQLDialect"/>
</properties>
</persistence-unit>

作为旁注,这是我们在某些特殊情况下必须帮助 bean 管理器的 CDIBeanUtils。在这种情况下,我们使用它来查找对 HttpServletRequest 和 Principal 的引用。

public class CDIBeanUtils {

public static <T> T getBean(Class<T> beanClass) {

BeanManager bm = CDI.current().getBeanManager();

Iterator<Bean<?>> ite = bm.getBeans(beanClass).iterator();
if (!ite.hasNext()) {
return null;
}
final Bean<T> bean = (Bean<T>) ite.next();
final CreationalContext<T> ctx = bm.createCreationalContext(bean);
final T t = (T) bm.getReference(bean, beanClass, ctx);
return t;
}

}

公平地说,这并不是完全拦截交易事件。但是我们能够在交易中包含我们需要的自定义查询。

希望这可以帮助其他人避免我们经历的痛苦。

关于java - 如何拦截 JTA 事务事件并获取对与事务关联的当前 EntityManager 的引用,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/25553048/

31 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com