网站建设行业推广,wordpress主题如何安装,贵阳网络公司网站建设,新手引导做的差的网站介绍
对我来说#xff0c;最令人困惑和不清楚的事情之一是#xff0c;作为Java开发人员#xff0c;一直是围绕事务管理的谜团#xff0c;尤其是JPA如何处理事务管理。 事务什么时候开始#xff0c;什么时候结束#xff0c;实体的持久化方式#xff0c;持久性上下文等等…介绍
对我来说最令人困惑和不清楚的事情之一是作为Java开发人员一直是围绕事务管理的谜团尤其是JPA如何处理事务管理。 事务什么时候开始什么时候结束实体的持久化方式持久性上下文等等。 诸如Spring之类的框架也无助于理解概念因为它们提供了另一层抽象这使事情难以理解。 在今天的帖子中我将尝试揭露JPA关于实体管理的规范其事务规范以及如何更好地理解该概念如何帮助我们有效地设计和编码的某些秘密。 我们将努力保持讨论 尽管我们将同时研究Java SE其中没有Java EE容器和基于Java EE的示例。
基本概念
在深入探讨更多细节之前让我们快速完成一些基础课程及其在JPA中的含义。
EntityManager –一个管理实体的持久状态或生命周期的类。持久性单元 –是实体类的命名配置。持久性上下文 –是一组托管的实体实例。 实体类是持久性单元配置的一部分。托管实体 –如果实体实例是持久性上下文的一部分并且该实体管理器可以对其执行操作则该实体实例将受到管理。
从上面的第一点和第三点我们可以推断出实体管理器总是管理持久性上下文。 因此如果我们了解持久性上下文我们将了解EntityManager。
细节
JPA中的EntityManager
JPA中定义了EntityManager的三种主要类型。
容器管理和交易范围的实体管理器容器管理和扩展范围实体管理器应用程序管理的实体管理器
现在我们将更详细地介绍其中的每一个。
容器管理的实体管理器
当应用程序的一个容器例如Java EE容器或任何其他自定义容器例如Spring管理实体管理器的生命周期时该实体管理器被称为“容器管理”。 获取容器管理的EntityManager的最常见方法是在EntityManager属性上使用PersistenceContext批注。 这是定义EntityManager的示例。 public class EmployeeServiceImpl implements EmployeeService { PersistenceContext(unitNameEmployeeService) EntityManager em; public void assignEmployeeToProject(int empId, int projectId) { Project project em.find(Project.class, projectId); Employee employee em.find(Employee.class, empId); project.getEmployees().add(employee); employee.getProjects().add(project); }
在上面的示例中我们在EntityManager类型实例变量上使用了PersistenceContext批注。 PersistenceContext批注具有属性“ unitName”用于标识该上下文的持久性单元。
容器管理的实体管理器有两种形式
交易范围的实体管理器扩展范围实体管理器
请注意上述范围实际上是指实体管理器管理的持久性上下文的范围。 它不是EntityManager本身的范围。
让我们依次查看它们中的每一个。
交易范围实体管理器
这是应用程序中最常用的实体管理器。 同样在上面的示例中我们实际上是在创建事务作用域实体管理器。 每当解析由PersistenceContext创建的引用时都会返回事务作用域实体管理器。
使用事务作用域实体管理器的最大好处是它是无状态的。 这也使事务范围的EntityManager线程安全因此实际上无需维护。 但是我们只是说EntityManager管理实体的持久状态而实体的持久状态是注入EntityManager的持久性上下文的一部分。 那么上述关于无国籍状态的说法又如何呢
答案在于所有容器管理的实体管理器都依赖于JTA事务。 每次在实体管理器上调用操作时容器代理容器在实例化时在实体管理器周围创建一个代理都会检查JTA事务上是否存在任何持久性上下文。 如果找到一个则实体管理器将使用此持久性上下文。 如果找不到则将创建一个新的持久性上下文并将其与事务关联。
让我们以上面讨论的相同示例来了解实体管理器和事务创建的概念。 public class EmployeeServiceImpl implements EmployeeService { PersistenceContext(unitNameEmployeeService) EntityManager em; public void assignEmployeeToProject(int empId, int projectId) { Project project em.find(Project.class, projectId); Employee employee em.find(Employee.class, empId); project.getEmployees().add(employee); employee.getProjects().add(project); }
在上面的示例中assignEmployeeToProject方法的第一行正在EntityManager上调用find方法。 查找调用将强制容器检查现有交易。 是否存在事务例如对于Java EE中的无状态会话Bean容器在每次调用Bean上的方法时都保证事务可用或不存在。 如果事务不存在它将抛出异常。 如果存在它将检查持久性上下文是否存在。 自从第一次调用EntityManager的任何方法以来持久性上下文尚不可用。 然后实体管理器将创建一个并使用它来查找项目bean实例。
在下一个查找调用中实体管理器已经具有关联的事务以及与其关联的持久性上下文。 它使用相同的事务来查找员工实例。 在方法的第二行结束时将同时管理项目和员工实例。 在方法调用结束时将提交事务并保留人员和员工的托管实例。 要记住的另一件事是当事务结束时持久性上下文消失了。
扩展范围实体管理器
如果并且当您希望持久性上下文在方法范围之外可用时请使用具有扩展范围的实体管理器。 理解扩展范围实体管理器的最好方法是以一个类为例该类需要维护某种状态该状态是由于诸如myEntityManager.find“ employeeId”之类的事务请求而创建的然后使用该雇员并且通过各种业务方法共享状态。
因为Persistence Context在方法调用之间共享并且用于维护状态所以除非您在有状态会话Bean中使用它们容器负责使其成为线程安全的否则它通常不是线程安全的。 重申一下如果您使用的是Java EE容器则将在Stateful Session Bean带有Stateful注释的类内使用扩展范围实体管理器。 如果您决定在有状态bean之外使用它则该容器不能保证您可以安全地执行线程操作而必须自己处理。 如果您使用的是像Spring这样的第三方容器情况也是如此。
让我们看一下使用状态会话Bean时Java EE环境中扩展作用域实体管理器的示例。
该示例中的目标是创建一个业务类该业务类具有在LibraryUser Entity实例上工作的业务方法。 让我们将此具有业务接口UserManagementService的业务类LibraryUserManagementService命名。 LibraryUserManagementService在LibraryUsers实体实例上工作。 图书馆可以将多本书借给LibraryUser。
这是描述上述情况的有状态会话Bean的示例。 Stateful public class LibraryUserManagementService implements UserManagementService { PersistenceContext(unitNameUserService) EntityManager em; LibraryUser user; public void init(String userId) { user em.find(LibraryUser.class, userId); } public void setUserName(String name) { user.setName(name); } public void borrowBookFromLibrary(BookId bookId) { Book book em.find(Book.class, bookId); user.getBooks().add(book); book.setLendingUser(user); } // ... Remove public void finished() { } }
在上面使用用户实例的情况下更自然的是先获得一个实例然后逐步进行操作只有完成后我们才应保留用户实例。 但是问题在于实体管理器是事务范围的。 这意味着init将在其自身的事务中运行因此具有其自身的持久性上下文而roweBookFromLibrary将在其自身的事务中运行。 结果init方法一结束用户对象就变得不受管理。
为了确切地解决此类问题我们使用PersistenceContextType.EXTENDED类型的实体管理器。
这是带有PersistenceContextType EXTENDED的修改后的示例可以很好地工作。 Stateful public class LibraryUserManagementService implements UserManagementService { PersistenceContext(unitNameUserService , typePersistenceContextType.EXTENDED) EntityManager em; LibraryUser user; public void init(String userId) { user em.find(LibraryUser.class, userId); } public void setUserName(String name) { user.setName(name); } public void borrowBookFromLibrary(BookId bookId) { Book book em.find(Book.class, bookId); user.getBooks().add(book); book.setLendingUser(user); } // ... Remove public void finished() { } }
在上述场景中用于管理用户实例的PersistenceContext是由Java EE容器在Bean初始化时创建的并且在调用完成的方法在该时间提交事务之前可用。
应用范围的实体管理器
不是由容器而是由应用程序本身创建的实体管理器是应用程序范围的实体管理器。 为了使定义更清晰每当我们通过在EntityManagerFactory实例上调用createEntityManager来创建实体管理器时实际上是在创建应用程序范围的实体管理器。 所有基于Java SE的应用程序实际上都使用应用程序范围的实体管理器。 JPA为我们提供了一个Persistence类该类用于最终创建应用程序范围的实体管理器。
以下是如何创建应用程序范围的EM的示例 EntityManagerFactory emf Persistence.createEntityManagerFactory(myPersistenceUnit); EntityManager em emf.createEntityManager();
请注意要创建应用程序范围的EntityManager在应用程序的META-INF文件夹中需要有一个persistence.xml文件。
EntityManager可以通过两种方式创建。 上面已经显示了一个。 创建EntityManager的另一种方法是将一组属性作为参数传递给 createEntityManagerFactory方法。 EntityManagerFactory emf Persistence.createEntityManagerFactory(myPersistenceUnit , myProperties); EntityManager em emf.createEntityManager();
如果要创建自己的应用程序托管实体管理器请确保在每次使用完它后都将其关闭。 这是必需的因为您现在正在管理应如何以及何时创建和使用EntityManager。
交易管理
交易与实体直接相关。 实质上管理事务意味着要管理实体生命周期创建更新删除的管理方式。 理解事务管理的另一个关键是要了解持久性上下文如何与事务交互。 值得注意的是从最终用户的角度来看即使我们使用EntityManager的实例EntityManager的唯一作用是确定持久性上下文的生存期。 它在决定持久化上下文应如何表现方面没有任何作用。 重申一下持久性上下文是一组实体实例的托管集合。 每当事务开始时Persistence Context实例都会与之关联。 当事务结束时例如提交持久性上下文将被刷新并与事务解除关联。
JPA支持两种类型的事务管理类型。
资源本地交易JTA或全球交易
资源本地事务是指JDBC驱动程序的本机事务而JTA事务是指JEE服务器的事务。 资源本地事务涉及单个事务资源例如JDBC连接。 每当在单个事务中需要两个或更多资源例如JMS连接和JDBC连接时都可以使用JTA事务。 容器管理的实体管理器始终使用JTA事务因为容器负责事务生命周期管理并在多个事务资源中产生事务。 应用程序管理的实体管理器可以使用资源本地事务或JTA事务。
通常在JTA或全局事务中第三方事务监控器会在事务中获取不同的事务资源为提交做准备最后提交事务。 首先准备事务资源通过空运行然后提交或回滚的过程称为两阶段提交。
有关XA协议的附带说明 –在全球交易中交易监视器必须不断与不同的交易资源进行对话。 不同的交易资源会说不同的语言因此交易监视器可能无法理解。 XA是一个协议规范为事务监视器与不同的事务资源进行交互提供了通用基础。 JTA是说XA的全球事务监控器规范因此能够管理多个事务资源。 兼容Java EE的服务器具有内置的JTA实现。其他容器例如Spring可以自己编写或使用其他实现例如Java Open Transaction ManagerJBoss TS等来支持JTA或全局事务。
持久性上下文事务和实体管理器
持久性上下文可以与单个或多个事务关联也可以与多个实体管理器关联。 持久性上下文已向事务注册以便在提交事务时可以刷新持久性上下文。 事务开始时实体管理器将查找活动的持久性上下文实例。 如果不可用它将创建一个并将其绑定到事务。 通常持久性上下文的范围与事务紧密相关。 当事务结束时与该事务关联的持久性上下文实例也结束。 但是有时在大多数情况下在Java EE世界中我们需要事务传播这是在单个事务中的不同实体管理器之间共享单个持久性上下文的过程。
持久性上下文可以有两个范围
事务范围的持久性上下文扩展范围的持久性上下文
我们已经讨论了事务/扩展范围的实体管理器并且我们也知道实体管理器可以是事务或扩展范围的。 关系不是偶然的。 事务范围的实体管理器创建事务范围的持久性上下文。 扩展范围实体管理器使用扩展持久性上下文。 扩展持久性上下文的生命周期与Java EE环境中的有状态会话Bean相关联。
让我们简要地讨论这些持久性上下文
事务范围的持久性上下文
TSPC仅在需要时由实体管理器创建。 仅当首次调用实体管理器上的方法时事务作用域实体管理器才创建TSPC。 因此持久性上下文的创建是懒惰的。 如果已经存在传播的持久性上下文则实体管理器将使用该持久性上下文。
了解持久性上下文传播对于识别和调试代码中与事务相关的问题非常重要。 让我们看一个如何传播事务范围的持久性上下文的示例。
ItemDAOImpl.java public class ItemDAOImpl implements ItemDAO { PersistenceContext(unitNameItemService) EntityManager em; LoggingService ls; TransactionAttribute() public void createItem(Item item) { em.persist(item); ls.log(item.getId(), created item); } // ... }
LoggingService.java public class LoggingService implements AuditService { PersistenceContext(unitNameItemService) EntityManager em; TransactionAttribute() public void log(int itemId, String action) { // verify item id is valid if (em.find(Item.class, itemId) null) { throw new IllegalArgumentException(Unknown item id); } LogRecord lr new LogRecord(itemId, action); em.persist(lr); } }
调用ItemDAOImpl的createItem方法时将在实体管理器实例上调用persist方法。 假设这是对实体管理器方法的第一次调用。 实体管理器将查找单元名称为“ ItemService”的任何传播的持久性上下文。 它找不到一个因为这是对实体管理器的第一个调用。 因此它创建了一个新的持久性上下文实例并将其附加到自身。 然后它继续保存Item对象。 持久化项目对象后我们将调用以记录刚刚持久化的项目信息。 请注意LoggingService有其自己的EnitityManager实例方法日志中具有注释TransactionAttribute如果在Java EE envt中并且将bean声明为EJB则不需要此注释。 由于TransactionAttribute的默认TransactionAttributeType为REQUIRED因此LoggingService中的实体管理器将查找以前的事务中可能可用的任何持久性上下文。 它找到一个在ItemDAOImpl的createItem方法内部创建的对象并使用相同的对象。 这就是为什么即使实际项目尚未持久到数据库因为尚未提交事务LoggingService中的实体管理器仍能够找到它因为持久性上下文已从ItemDAOImpl传播到LoggingService 。
扩展持久性上下文
事务范围持久性上下文是为每个事务创建的在不传播的情况下而扩展持久性上下文仅创建一次并由管理扩展持久性上下文生命周期的类范围内的所有事务使用。 对于Java EE由状态会话Bean管理扩展的持久性上下文的生命周期。 有状态会话bean的创建是EAGER。 如果是容器托管事务则在类上的方法被调用后立即创建它。 对于应用程序管理的事务将在调用userTransaction.begin时创建。
摘要
在这篇博客文章中已经讨论了很多东西实体管理器事务管理持久性上下文所有这些东西如何相互作用以及如何相互配合。
我们讨论了容器管理的实体管理器和应用程序管理的实体管理器事务范围和扩展范围持久性上下文事务传播之间的区别。 该博客的大部分材料是阅读了精彩的书 Pro JPA 2的结果 。 如果您想更深入地了解JPA的工作原理我建议您阅读它。
参考 JPA 2 | JavaWorld博客博客中的JCG合作伙伴 Anuj Kumar提供了EntityManagersTransactions及其周围的一切 。 翻译自: https://www.javacodegeeks.com/2013/06/jpa-2-entitymanagers-transactions-and-everything-around-it.html jpa 事务嵌套事务
