@ -78,11 +78,16 @@ public class HibernateJpaVendorAdapter extends AbstractJpaVendorAdapter {
@@ -78,11 +78,16 @@ public class HibernateJpaVendorAdapter extends AbstractJpaVendorAdapter {
@ -686,9 +686,8 @@ case, the `txManager` bean.
@@ -686,9 +686,8 @@ case, the `txManager` bean.
[TIP]
====
You can omit the `transaction-manager` attribute in the transactional advice (
`<tx:advice/>`) if the bean name of the `PlatformTransactionManager` that you want to
You can omit the `transaction-manager` attribute in the transactional advice
(`<tx:advice/>`) if the bean name of the `PlatformTransactionManager` that you want to
wire in has the name `transactionManager`. If the `PlatformTransactionManager` bean that
you want to wire in has any other name, then you must use the `transaction-manager`
attribute explicitly, as in the preceding example.
@ -1950,7 +1949,6 @@ transaction in which it has been published as committed successfully:
@@ -1950,7 +1949,6 @@ transaction in which it has been published as committed successfully:
public void handleOrderCreatedEvent(CreationEvent<Order> creationEvent) {
...
}
}
----
@ -1994,9 +1992,9 @@ explicitly; rather, they are chosen automatically, with the standard
@@ -1994,9 +1992,9 @@ explicitly; rather, they are chosen automatically, with the standard
==== IBM WebSphere
On WebSphere 6.1.0.9 and above, the recommended Spring JTA transaction manager to use is
`WebSphereUowTransactionManager`. This special adapter leverages IBM's `UOWManager` API,
which is available in WebSphere Application Server 6.0.2.19 and later and 6.1.0.9 and
later. With this adapter, Spring-driven transaction suspension (suspend/resume as
initiated by `PROPAGATION_REQUIRES_NEW`) is officially supported by IBM!
which is available in WebSphere Application Server 6.1.0.9 and later. With this adapter,
Spring-driven transaction suspension (suspend/resume as initiated by
`PROPAGATION_REQUIRES_NEW`) is officially supported by IBM.
The `org.springframework.jdbc.datasource.init` package provides support for initializing
an existing `DataSource`. The embedded database support provides one option for creating
@ -4942,6 +4940,7 @@ The second option can also be easy. Some suggestions on how to implement this in
@@ -4942,6 +4940,7 @@ The second option can also be easy. Some suggestions on how to implement this in
[[orm]]
== Object Relational Mapping (ORM) Data Access
@ -5125,9 +5124,10 @@ chapter will then cover the other ORM technologies, showing briefer examples the
@@ -5125,9 +5124,10 @@ chapter will then cover the other ORM technologies, showing briefer examples the
[NOTE]
====
As of Spring 4.0, Spring requires Hibernate 3.6 or later. Note that the Hibernate team
stopped supporting Hibernate 3 years ago and even phased out support for Hibernate 4.x
in late 2015. We therefore recommend Hibernate 5.1 and higher from a 2016+ perspective.
As of Spring 5.0, Spring requires Hibernate ORM 4.3 or later for JPA support and even
Hibernate ORM 5.0+ for programming against the native Hibernate Session API. Note that
the Hibernate team does not maintain any versions prior to 5.0 anymore and is likely
to focus on 5.2+ exclusively soon.
====
@ -5272,7 +5272,7 @@ able to participate in Spring-managed transactions.
@@ -5272,7 +5272,7 @@ able to participate in Spring-managed transactions.
We recommend that you use Spring's declarative transaction support, which enables you to
replace explicit transaction demarcation API calls in your Java code with an AOP
transaction interceptor. This transaction interceptor can be configured in a Spring
container using either Java annotations or XML.This declarative transaction capability
container using either Java annotations or XML.This declarative transaction capability
allows you to keep business services free of repetitive transaction demarcation code and
to focus on adding business logic, which is the real value of your application.
@ -5282,83 +5282,9 @@ Prior to continuing, you are __strongly__ encouraged to read <<transaction-decla
@@ -5282,83 +5282,9 @@ Prior to continuing, you are __strongly__ encouraged to read <<transaction-decla
if you have not done so.
====
Furthermore, transaction semantics like propagation behavior and isolation level can be
changed in a configuration file and do not affect the business service implementations.
The following example shows how you can configure an AOP transaction interceptor, using
As you can see from the following configuration example, the configuration is much
simplified, compared to the XML example above, while still providing the same
functionality driven by the annotations in the service layer code. All you need to
provide is the TransactionManager implementation and a "<tx:annotation-driven/>" entry.
All you need to set up in the container is the `PlatformTransactionManager`
implementation as a bean as well as a "<tx:annotation-driven/>" entry,
opting into `@Transactional` processing at runtime.
[source,xml,indent=0]
[subs="verbatim,quotes"]
@ -5510,78 +5435,6 @@ sources are transactional container ones, a business service can demarcate trans
@@ -5510,78 +5435,6 @@ sources are transactional container ones, a business service can demarcate trans
across any number of DAOs and any number of session factories without special regard, as
long as it is using `JtaTransactionManager` as the strategy.
Both `HibernateTransactionManager` and `JtaTransactionManager` allow for proper
JVM-level cache handling with Hibernate, without container-specific transaction manager
lookup or a JCA connector (if you are not using EJB to initiate transactions).
@ -5767,12 +5620,12 @@ the JPA specification is designed.
@@ -5767,12 +5620,12 @@ the JPA specification is designed.
[NOTE]
====
Use this option when deploying to a Java EE 5 server. Check your server's documentation
Use this option when deploying to a Java EE server. Check your server's documentation
on how to deploy a custom JPA provider into your server, allowing for a different
provider than the server's default.
====
Obtaining an `EntityManagerFactory` from JNDI (for example in a Java EE 5 environment),
Obtaining an `EntityManagerFactory` from JNDI (for example in a Java EE environment),
is simply a matter of changing the XML configuration:
[source,xml,indent=0]
@ -5783,7 +5636,7 @@ is simply a matter of changing the XML configuration:
@@ -5783,7 +5636,7 @@ is simply a matter of changing the XML configuration:
</beans>
----
This action assumes standard Java EE 5 bootstrapping: the Java EE server autodetects
This action assumes standard Java EE bootstrapping: the Java EE server autodetects
persistence units (in effect, `META-INF/persistence.xml` files in application jars) and
`persistence-unit-ref` entries in the Java EE deployment descriptor (for example,
`web.xml`) and defines environment naming context locations for those persistence units.
@ -5864,20 +5717,20 @@ so on. However, it also imposes requirements on the runtime environment, such as
@@ -5864,20 +5717,20 @@ so on. However, it also imposes requirements on the runtime environment, such as
availability of a weaving-capable class loader if the persistence provider demands
byte-code transformation.
This option may conflict with the built-in JPA capabilities of a Java EE 5 server. In a
full Java EE 5 environment, consider obtaining your `EntityManagerFactory` from JNDI.
This option may conflict with the built-in JPA capabilities of a Java EE server. In a
full Java EE environment, consider obtaining your `EntityManagerFactory` from JNDI.
Alternatively, specify a custom `persistenceXmlLocation` on your
`LocalContainerEntityManagerFactoryBean` definition, for example,
META-INF/my-persistence.xml, and only include a descriptor with that name in your
application jar files. Because the Java EE 5 server only looks for default
application jar files. Because the Java EE server only looks for default
`META-INF/persistence.xml` files, it ignores such custom persistence units and hence
avoid conflicts with a Spring-driven JPA setup upfront. (This applies to Resin 3.1, for
example.)
.When is load-time weaving required?
****
Not all JPA providers require a JVM agent ; Hibernate is an example of one that does
not. If your provider does not require an agent or you have other alternatives, such as
Not all JPA providers require a JVM agent. Hibernate is an example of one that does not.
If your provider does not require an agent or you have other alternatives, such as
applying enhancements at build time through a custom compiler or an ant task, the
load-time weaver __should not__ be used.
****
@ -5936,7 +5789,7 @@ implementations because the JPA transformers are applied only at class loader le
@@ -5936,7 +5789,7 @@ implementations because the JPA transformers are applied only at class loader le
thus are isolated from each other.
[[orm-jpa-multiple-pu]]
[[orm-jpa-multiple]]
===== Dealing with multiple persistence units
For applications that rely on multiple persistence units locations, stored in various
JARS in the classpath, for example, Spring offers the `PersistenceUnitManager` to act as
@ -5981,8 +5834,8 @@ affect __all__ hosted units, or programmatically, through the
@@ -5981,8 +5834,8 @@ affect __all__ hosted units, or programmatically, through the
[[orm-jpa-straight]]
==== Implementing DAOs based on plain JPA
[[orm-jpa-dao]]
==== Implementing DAOs based on JPA: EntityManagerFactory and EntityManager
[NOTE]
====
Although `EntityManagerFactory` instances are thread-safe, `EntityManager` instances are
@ -6104,7 +5957,7 @@ protected, private) does not matter.
@@ -6104,7 +5957,7 @@ protected, private) does not matter.
What about class-level annotations?
On the Java EE 5 platform, they are used for dependency declaration and not for resource
On the Java EE platform, they are used for dependency declaration and not for resource
injection.
****
@ -6121,58 +5974,21 @@ a non-invasiveness perspective, and might feel more natural to JPA developers.
@@ -6121,58 +5974,21 @@ a non-invasiveness perspective, and might feel more natural to JPA developers.
[[orm-jpa-tx]]
==== Transaction Management
==== Spring-driven JPA transactions
[NOTE]
====
You are __strongly__ encouraged to read <<transaction-declarative>> if you have not done
so, to get a more detailed coverage of Spring's declarative transaction support.
====
To execute service operations within transactions, you can use Spring's common
Spring JPA allows a configured `JpaTransactionManager` to expose a JPA transaction to
JDBC access code that accesses the same JDBC `DataSource`, provided that the registered
Spring JPA also allows a configured `JpaTransactionManager` to expose a JPA transaction
to JDBC access code that accesses the same `DataSource`, provided that the registered
`JpaDialect` supports retrieval of the underlying JDBC `Connection`. Out of the box,
Spring provides dialects for the EclipseLink and Hibernate JPA implementations.
See the next section for details on the `JpaDialect` mechanism.
@ -6180,7 +5996,7 @@ See the next section for details on the `JpaDialect` mechanism.
@@ -6180,7 +5996,7 @@ See the next section for details on the `JpaDialect` mechanism.
[[orm-jpa-dialect]]
==== JpaDialect
==== JpaDialect and JpaVendorAdapter
As an advanced feature `JpaTransactionManager` and subclasses of
`AbstractEntityManagerFactoryBean` support a custom `JpaDialect`, to be passed into the
@ -6193,12 +6009,61 @@ features supported by Spring, usually in a vendor-specific manner:
@@ -6193,12 +6009,61 @@ features supported by Spring, usually in a vendor-specific manner:
* Advanced translation of `PersistenceExceptions` to Spring `DataAccessExceptions`
This is particularly valuable for special transaction semantics and for advanced
translation of exception. The default implementation used ( `DefaultJpaDialect`) does
not provide any special capabilities and if the above features are required, you have to
specify the appropriate dialect.
translation of exception. The default implementation used (`DefaultJpaDialect`) does
not provide any special capabilities and if the above features are required, you have
to specify the appropriate dialect.
[TIP]
====
As an even broader provider adaptation facility primarily for Spring's full-featured
`LocalContainerEntityManagerFactoryBean` setup, `JpaVendorAdapter` combines the
capabilities of `JpaDialect` with other provider-specific defaults. Specifying a
`HibernateJpaVendorAdapter` or `EclipseLinkJpaVendorAdapter` is the most convenient
way of auto-configuring an `EntityManagerFactory` setup for Hibernate or EclipseLink,
respectively. Note that those provider adapters are primarily designed for use with
Spring-driven transaction management, i.e. for use with `JpaTransactionManager`.
====
See the `JpaDialect` and `JpaVendorAdapter` javadocs for more details of its operations
and how they are used within Spring's JPA support.
[[orm-jpa-jta]]
==== Setting up JPA with JTA transaction management
As an alternative to `JpaTransactionManager`, Spring also allows for multi-resource
transaction coordination via JTA, either in a Java EE environment or with a
standalone transaction coordinator such as Atomikos. Aside from choosing Spring's
`JtaTransactionManager` instead of `JpaTransactionManager`, there are a few further
steps to take:
* The underlying JDBC connection pools need to be XA-capable and integrated with
your transaction coordinator. This is usually straightforward in a Java EE environment,
simply exposing a different kind of `DataSource` via JNDI. Check your application server
documentation for details. Analogously, a standalone transaction coordinator usually
comes with special XA-integrated `DataSource` implementations; again, check its docs.
* The JPA `EntityManagerFactory` setup needs to be configured for JTA. This is
provider-specific, typically via special properties to be specified as "jpaProperties"
on `LocalContainerEntityManagerFactoryBean`. In the case of Hibernate, these properties
are even version-specific; please check your Hibernate documentation for details.
* Spring's `HibernateJpaVendorAdapter` enforces certain Spring-oriented defaults such
as the connection release mode "on-close" which matches Hibernate's own default in
Hibernate 5.0 but not anymore in 5.1/5.2. For a JTA setup, either do not declare
`HibernateJpaVendorAdapter` to begin with, or turn off its `prepareConnection` flag.
Alternatively, set Hibernate 5.2's "hibernate.connection.handling_mode" property to
"DELAYED_ACQUISITION_AND_RELEASE_AFTER_STATEMENT" to restore Hibernate's own default.
See <<orm-hibernate-invalid-jdbc-access-error>> for a related note about WebLogic.
* Alternatively, consider obtaining the `EntityManagerFactory` from your application
server itself, i.e. via a JNDI lookup instead of a locally declared
`LocalContainerEntityManagerFactoryBean`. A server-provided `EntityManagerFactory`
might require special definitions in your server configuration, making the deployment
less portable, but will be set up for the server's JTA environment out of the box.
See the `JpaDialect` javadocs for more details of its operations and how they are used
within Spring's JPA support.
[[oxm]]
@ -6260,8 +6125,7 @@ the two Spring interfaces used for this purpose.
@@ -6260,8 +6125,7 @@ the two Spring interfaces used for this purpose.
[[oxm-marshaller]]
==== Marshaller
Spring abstracts all marshalling operations behind the
`org.springframework.oxm.Marshaller` interface, the main methods of which is listed
below.
`org.springframework.oxm.Marshaller` interface, the main method of which is shown below.
Juergen Hoeller
8 years ago