blocks|key|1012605|text|关键是要有一个像你期望的那样工作的应用程序，而且不会太慢。让我们举一个例子：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1012606|Order+order+=+em.find(Order.class,+3L);
Customer+customer+=+em.find(Customer.class,+5L);
for+(Order+o+:+customer.getOrders())+{+//+line+A
++++if+(o.getId().longValue+==+3L)+{
++++++++o.setComment("hello");+//+line+B
++++++++o.setModifier("John");+
++++}
}

System.out.println(order.getComment));+//+line+C

for+(Order+o+:+customer.getOrders())+{+//+line+D
++++System.out.println(o.getComment());+//+line+E
}|code-block|syntax|javascript|1012607|在A行，JPA执行一个SQL查询来加载客户的所有订单。|1012608|在C行，你希望打印什么？null还是"hello"？您期望打印"hello“，因为您在B行修改的顺序与第一行中加载的ID相同。如果没有第一级缓存，那是不可能的。|offset|length|style|CODE|1012609|在D行，您不会期望订单再次从数据库中加载，因为它们已经加载在A行了。如果没有第一级缓存，这是不可能的。|1012610|在E行，您需要再次为订单3打印"hello“，如果没有第一级缓存，这是不可能的。|1012611|在B行，您不希望执行更新查询，因为可能会对同一实体进行许多后续修改(如下一行)。因此，您希望在事务结束时，这些修改将尽可能晚地写入数据库。如果没有第一级缓存，那是不可能的。|1012612|entityMap^0|0|0|0|C|4|I|7|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Y|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|Z|8|@$K|10|L|11|M|N]|$K|12|L|13|M|N]]|9|@]|A|$]]|$1|O|3|P|5|6|7|14|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|15|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|16|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|V|$]]

The point is to have an application that works like you expect it to work, and that wouldn't be slow as hell. Let's take an example:

<pre><code>Order order = em.find(Order.class, 3L);
Customer customer = em.find(Customer.class, 5L);
for (Order o : customer.getOrders()) { // line A
 if (o.getId().longValue == 3L) {
 o.setComment("hello"); // line B
 o.setModifier("John"); 
 }
}

System.out.println(order.getComment)); // line C

for (Order o : customer.getOrders()) { // line D
 System.out.println(o.getComment()); // line E
}
</code></pre>

At line A, JPA executes a SQL query to load all the orders of the customer.

At line C, what do you expect to be printed? <code>null</code> or <code>"hello"</code>? You expect "hello" to be printed, because the order you modified at line B has the same ID as the one loaded in the first line. That wouldn't be possible without the first-level cache.

At line D, you don't expect the orders to be loaded again from the database, because they have already been loaded at line A. That wouldn't be possible without the first-level cache.

At line E, you expect once again "hello" to be printed for the order 3. That wouldn't be possible without the first-level cache.

At line B, you don't expect an update query to be executed, because there might be many subsequent modifications (like in the next line), to the same entity. So you expect these modifications to be written to the database as late as possible, all in one go, at the end of the transaction. That wouldn't be possible without the first-level cache.

blocks|key|2011321|text|第一级缓存用于其他目的。它基本上是JPA放置从数据库检索的实体的上下文。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2011322|性能|offset|length|style|BOLD|2011323|因此，为了开始声明显而易见的内容，它避免了在事务处理和提高性能期间已经检索了作为某种形式的缓存的记录。另外，考虑一下延迟加载。如何在没有缓存的情况下实现它来记录已经被延迟加载的实体？|2011324|循环关系|2011325|这种缓存功能对于实现适当的ORM框架至关重要。在面向对象语言中，对象图具有循环关系是很常见的.例如，具有Employee对象和这些Employee对象的部门属于部门。|2011326|如果没有上下文(也称为工作单位)，就很难跟踪您已经拥有ORMed的记录，最终将创建新的对象，在这种情况下，您甚至可能会陷入无限循环。|2011327|跟踪更改:提交和回滚|2011328|此外，此上下文跟踪您对对象所做的更改，以便在事务结束后的某个时间点将其持久化或回滚。如果没有这样的缓存，您将被迫在更改发生时立即将更改刷新到数据库，然后就无法回滚，也无法优化将它们刷新到存储的最佳时机。|2011329|对象标识|2011330|对象标识在ORM框架中也至关重要。也就是说，如果您检索员工ID+123，那么如果在某个时候需要该雇员，您应该始终获得相同的对象，而不是包含相同数据的新对象。|2011331|这种类型的缓存不能由多个线程共享，如果是这样的话，您将损害性能，并迫使每个人付出代价，即使他们只需要单线程解决方案就可以了。除此之外，你最终会得到一个更复杂的解决方案，就像用火箭筒杀死一只苍蝇。|2011332|这就是为什么如果您需要的是一个共享缓存，那么您实际上需要一个二级缓存，并且也有实现。|2011333|entityMap|0|LINK|mutability|MUTABLE|url|http://martinfowler.com/eaaCatalog/unitOfWork.html^0|0|0|2|0|0|0|4|0|0|B|4|0|0|0|A|0|0|0|4|0|0|0|0^^$0|@$1|2|3|4|5|6|7|19|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1A|8|@$D|1B|E|1C|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1D|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1E|8|@$D|1F|E|1G|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|1H|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1I|8|@]|9|@$D|1J|E|1K|1|1L]]|A|$]]|$1|P|3|Q|5|6|7|1M|8|@$D|1N|E|1O|F|G]]|9|@]|A|$]]|$1|R|3|S|5|6|7|1P|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1Q|8|@$D|1R|E|1S|F|G]]|9|@]|A|$]]|$1|V|3|W|5|6|7|1T|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1U|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1V|8|@]|9|@]|A|$]]|$1|11|3|-4|5|6|7|1W|8|@]|9|@]|A|$]]]|12|$13|$5|14|15|16|A|$17|18]]]]

The first level cache serves other purposes. It is basically the context in which JPA places the entities retrieved from the database. 

Performance

So, to start stating the obvious, it avoids having to retrieve a record when it has already being retrieved serving as some form of cache during a transaction processing and improving performance. Also, think about lazy loading. How could you implement it without a cache to record entities that have already being lazy loaded?

Cyclic Relationships

This caching purpose is vital to the implementation of appropriate ORM frameworks. In object-oriented languages it is common that the object graph has cyclic relationships. For instance, a Department that has Employee objects and those Employee objects belong to a Department.

Without a context (aka as <a href="http://martinfowler.com/eaaCatalog/unitOfWork.html" rel="nofollow">Unit of Work</a>) it would be difficult to keep track of which records you have already ORMed and you would end up creating new objects, and in a case like this, you may even end up in an infinite loop.

Keep Track of Changes: Commit and Rollback

Also, this context keeps track of the changes you do to the objects so that they can be persisted or rolled back at some later point when the transaction ends. Without a cache like this you would be forced to flush your changes to the database immediately as they happen and then you could not rollback, neither could you optimize the best moment to flush them to the store.

Object Identity

Object identity is also vital in ORM frameworks. That is if you retrieve employee ID 123, then if at some time you need that Employee, you should always get the same object, and not some new Object containing the same data.

This type of cache is not to be shared by multiple threads, if it was so, you would compromise performance and force everyone to pay that penalty even when they could be just fine with a single-threaded solution. Besides the fact that you would end up with a much more complex solution that would be like killing a fly with a bazooka. 

That is the reason why if what you need is a shared cache, then you actually need a 2nd-level cache, and there are implementations for that as well.

EntityManager maintains first level cache for retrieved objects, but if you want to have threadsafe aplication you're creating and closing entityManager for each transaction.

So whats the point of the level 1 cache if those entities are created and closed for every transaction? Or entityManager cache is usable if youre working in single thread?

JPA and first level cache, whats the point?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

EntityManager为检索到的对象维护第一级缓存，但是如果您想拥有线程安全折叠，则需要为每个事务创建和关闭entityManager。那么，如果为每个事务创建和关闭了这些实体，那么第1级缓存的意义是什么？或者，如果您在单线程中工作，那么entityManager缓存是可用的？

问JPA和第一级缓存，有什么意义？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问JPA和第一级缓存，有什么意义？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问JPA和第一级缓存，有什么意义？
EN