@@ -281,17 +281,17 @@ Spring Data JPA, make sure to set up deferred bootstrapping for its repositories
281
281
[[orm-jpa-dao]]
282
282
== Implementing DAOs Based on JPA: `EntityManagerFactory` and `EntityManager`
283
283
284
- NOTE: Although `EntityManagerFactory` instances are thread-safe, `EntityManager` instances are
285
- not. The injected JPA `EntityManager` behaves like an `EntityManager` fetched from an
284
+ NOTE: Although `EntityManagerFactory` instances are thread-safe, `EntityManager` instances
285
+ are not. The injected JPA `EntityManager` behaves like an `EntityManager` fetched from an
286
286
application server's JNDI environment, as defined by the JPA specification. It delegates
287
287
all calls to the current transactional `EntityManager`, if any. Otherwise, it falls back
288
288
to a newly created `EntityManager` per operation, in effect making its usage thread-safe.
289
289
290
290
It is possible to write code against the plain JPA without any Spring dependencies, by
291
291
using an injected `EntityManagerFactory` or `EntityManager`. Spring can understand the
292
292
`@PersistenceUnit` and `@PersistenceContext` annotations both at the field and the method level
293
- if a `PersistenceAnnotationBeanPostProcessor` is enabled. The following example shows a plain JPA DAO implementation
294
- that uses the `@PersistenceUnit` annotation:
293
+ if a `PersistenceAnnotationBeanPostProcessor` is enabled. The following example shows a plain
294
+ JPA DAO implementation that uses the `@PersistenceUnit` annotation:
295
295
296
296
[tabs]
297
297
======
@@ -384,9 +384,9 @@ Consider the following example:
384
384
----
385
385
386
386
The main problem with such a DAO is that it always creates a new `EntityManager` through
387
- the factory. You can avoid this by requesting a transactional `EntityManager` (also
388
- called a "`shared EntityManager`" because it is a shared, thread-safe proxy for the actual
389
- transactional EntityManager) to be injected instead of the factory. The following example shows how to do so:
387
+ the factory. You can avoid this by requesting a transactional `EntityManager` (also called a
388
+ "`shared EntityManager`" because it is a shared, thread-safe proxy for the actual transactional
389
+ EntityManager) to be injected instead of the factory. The following example shows how to do so:
390
390
391
391
[tabs]
392
392
======
@@ -430,19 +430,19 @@ The `@PersistenceContext` annotation has an optional attribute called `type`, wh
430
430
`EntityManager` proxy. The alternative, `PersistenceContextType.EXTENDED`, is a completely
431
431
different affair. This results in a so-called extended `EntityManager`, which is not
432
432
thread-safe and, hence, must not be used in a concurrently accessed component, such as a
433
- Spring-managed singleton bean. Extended `EntityManager` instances are only supposed to be used in
434
- stateful components that, for example, reside in a session, with the lifecycle of the
433
+ Spring-managed singleton bean. Extended `EntityManager` instances are only supposed to be used#
434
+ in stateful components that, for example, reside in a session, with the lifecycle of the
435
435
`EntityManager` not tied to a current transaction but rather being completely up to the
436
436
application.
437
437
438
438
.Method- and field-level Injection
439
439
****
440
440
You can apply annotations that indicate dependency injections (such as `@PersistenceUnit` and
441
- `@PersistenceContext`) on field or methods inside a class -- hence the
442
- expressions "`method-level injection`" and "`field-level injection`". Field-level
443
- annotations are concise and easier to use while method-level annotations allow for further
444
- processing of the injected dependency. In both cases, the member visibility (public,
445
- protected, or private) does not matter.
441
+ `@PersistenceContext`) on field or methods inside a class -- hence the expressions
442
+ "`method-level injection`" and "`field-level injection`". Field-level annotations are
443
+ concise and easier to use while method-level annotations allow for further processing of the
444
+ injected dependency. In both cases, the member visibility (public, protected, or private)
445
+ does not matter.
446
446
447
447
What about class-level annotations?
448
448
@@ -451,9 +451,9 @@ injection.
451
451
****
452
452
453
453
The injected `EntityManager` is Spring-managed (aware of the ongoing transaction).
454
- Even though the new DAO implementation uses method-level
455
- injection of an `EntityManager` instead of an `EntityManagerFactory`, no change is
456
- required in the application context XML, due to annotation usage.
454
+ Even though the new DAO implementation uses method-level injection of an `EntityManager`
455
+ instead of an `EntityManagerFactory`, no change is required in the bean definition
456
+ due to annotation usage.
457
457
458
458
The main advantage of this DAO style is that it depends only on the Java Persistence API.
459
459
No import of any Spring class is required. Moreover, as the JPA annotations are understood,
0 commit comments