Spring/spring-framework
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix cross references

Browse Source
This commit is contained in:
Rob Winch
2023-04-19 10:26:17 -05:00
committed by rstoyanchev
parent 6b341ddf19
commit 139cde47e2
296 changed files with 1505 additions and 1505 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
framework-docs/modules/ROOT/pages/data-access/appendix.adoc
View File

@@ -9,8 +9,8 @@
This part of the appendix lists XML schemas for data access, including the following:
* <<xsd-schemas-tx>>
* <<xsd-schemas-jdbc>>
* xref:data-access/appendix.adoc#xsd-schemas-tx[The `tx` Schema]
* xref:data-access/appendix.adoc#xsd-schemas-jdbc[The `jdbc` Schema]
@@ -19,7 +19,7 @@ This part of the appendix lists XML schemas for data access, including the follo
The `tx` tags deal with configuring all of those beans in Spring's comprehensive support
for transactions. These tags are covered in the chapter entitled
<<data-access.adoc#transaction, Transaction Management>>.
xref:data-access/transaction.adoc[Transaction Management].
TIP: We strongly encourage you to look at the `'spring-tx.xsd'` file that ships with the
Spring distribution. This file contains the XML Schema for Spring's transaction
@@ -68,8 +68,8 @@ to you.
The `jdbc` elements let you quickly configure an embedded database or initialize an
existing data source. These elements are documented in
<<data-access.adoc#jdbc-embedded-database-support, Embedded Database Support>> and
<<data-access.adoc#jdbc-initializing-datasource, Initializing a DataSource>>, respectively.
xref:data-access/jdbc/embedded-database-support.adoc[Embedded Database Support] and
xref:data-access/jdbc/initializing-datasource.adoc[Initializing a DataSource], respectively.
To use the elements in the `jdbc` schema, you need to have the following preamble at the
top of your Spring XML configuration file. The text in the following snippet references

2
framework-docs/modules/ROOT/pages/data-access/jdbc/advanced.adoc
View File

@@ -198,7 +198,7 @@ While this usually works well, there is a potential for issues (for example, wit
case, which can be expensive with your JDBC driver. You should use a recent driver
version and consider setting the `spring.jdbc.getParameterType.ignore` property to `true`
(as a JVM system property or via the
<<appendix.adoc#appendix-spring-properties,`SpringProperties`>> mechanism) if you encounter
xref:appendix.adoc#appendix-spring-properties[`SpringProperties`] mechanism) if you encounter
a performance issue (as reported on Oracle 12c, JBoss, and PostgreSQL).
Alternatively, you might consider specifying the corresponding JDBC types explicitly,

16
framework-docs/modules/ROOT/pages/data-access/jdbc/connections.adoc
View File

@@ -3,14 +3,14 @@
This section covers:
* <<jdbc-datasource>>
* <<jdbc-DataSourceUtils>>
* <<jdbc-SmartDataSource>>
* <<jdbc-AbstractDataSource>>
* <<jdbc-SingleConnectionDataSource>>
* <<jdbc-DriverManagerDataSource>>
* <<jdbc-TransactionAwareDataSourceProxy>>
* <<jdbc-DataSourceTransactionManager>>
* xref:data-access/jdbc/connections.adoc#jdbc-datasource[Using `DataSource`]
* xref:data-access/jdbc/connections.adoc#jdbc-DataSourceUtils[Using `DataSourceUtils`]
* xref:data-access/jdbc/connections.adoc#jdbc-SmartDataSource[Implementing `SmartDataSource`]
* xref:data-access/jdbc/connections.adoc#jdbc-AbstractDataSource[Extending `AbstractDataSource`]
* xref:data-access/jdbc/connections.adoc#jdbc-SingleConnectionDataSource[Using `SingleConnectionDataSource`]
* xref:data-access/jdbc/connections.adoc#jdbc-DriverManagerDataSource[Using `DriverManagerDataSource`]
* xref:data-access/jdbc/connections.adoc#jdbc-TransactionAwareDataSourceProxy[Using `TransactionAwareDataSourceProxy`]
* xref:data-access/jdbc/connections.adoc#jdbc-DataSourceTransactionManager[Using `DataSourceTransactionManager`]
[[jdbc-datasource]]

22
framework-docs/modules/ROOT/pages/data-access/jdbc/core.adoc
View File

@@ -4,13 +4,13 @@
This section covers how to use the JDBC core classes to control basic JDBC processing,
including error handling. It includes the following topics:
* <<jdbc-JdbcTemplate>>
* <<jdbc-NamedParameterJdbcTemplate>>
* <<jdbc-SQLExceptionTranslator>>
* <<jdbc-statements-executing>>
* <<jdbc-statements-querying>>
* <<jdbc-updates>>
* <<jdbc-auto-generated-keys>>
* xref:data-access/jdbc/core.adoc#jdbc-JdbcTemplate[Using `JdbcTemplate`]
* xref:data-access/jdbc/core.adoc#jdbc-NamedParameterJdbcTemplate[Using `NamedParameterJdbcTemplate`]
* xref:data-access/jdbc/core.adoc#jdbc-SQLExceptionTranslator[Using `SQLExceptionTranslator`]
* xref:data-access/jdbc/core.adoc#jdbc-statements-executing[Running Statements]
* xref:data-access/jdbc/core.adoc#jdbc-statements-querying[Running Queries]
* xref:data-access/jdbc/core.adoc#jdbc-updates[Updating the Database]
* xref:data-access/jdbc/core.adoc#jdbc-auto-generated-keys[Retrieving Auto-generated Keys]
[[jdbc-JdbcTemplate]]
@@ -26,7 +26,7 @@ SQL and extract results. The `JdbcTemplate` class:
* Updates statements and stored procedure calls
* Performs iteration over `ResultSet` instances and extraction of returned parameter values.
* Catches JDBC exceptions and translates them to the generic, more informative, exception
hierarchy defined in the `org.springframework.dao` package. (See <<dao-exceptions>>.)
hierarchy defined in the `org.springframework.dao` package. (See xref:data-access/dao.adoc#dao-exceptions[Consistent Exception Hierarchy].)
When you use the `JdbcTemplate` for your code, you need only to implement callback
interfaces, giving them a clearly defined contract. Given a `Connection` provided by the
@@ -270,7 +270,7 @@ The following example invokes a stored procedure:
----
More sophisticated stored procedure support is <<jdbc-StoredProcedure, covered later>>.
More sophisticated stored procedure support is xref:data-access/jdbc/object.adoc#jdbc-StoredProcedure[covered later].
[[jdbc-JdbcTemplate-idioms]]
=== `JdbcTemplate` Best Practices
@@ -282,7 +282,7 @@ The `JdbcTemplate` is stateful, in that it maintains a reference to a `DataSourc
this state is not conversational state.
A common practice when using the `JdbcTemplate` class (and the associated
<<jdbc-NamedParameterJdbcTemplate, `NamedParameterJdbcTemplate`>> class) is to
xref:data-access/jdbc/core.adoc#jdbc-NamedParameterJdbcTemplate[`NamedParameterJdbcTemplate`] class) is to
configure a `DataSource` in your Spring configuration file and then dependency-inject
that shared `DataSource` bean into your DAO classes. The `JdbcTemplate` is created in
the setter for the `DataSource`. This leads to DAOs that resemble the following:
@@ -607,7 +607,7 @@ functionality that is present only in the `JdbcTemplate` class, you can use the
`getJdbcOperations()` method to access the wrapped `JdbcTemplate` through the
`JdbcOperations` interface.
See also <<jdbc-JdbcTemplate-idioms>> for guidelines on using the
See also xref:data-access/jdbc/core.adoc#jdbc-JdbcTemplate-idioms[`JdbcTemplate` Best Practices] for guidelines on using the
`NamedParameterJdbcTemplate` class in the context of an application.

10
framework-docs/modules/ROOT/pages/data-access/jdbc/embedded-database-support.adoc
View File

@@ -129,9 +129,9 @@ configuration, as the following example shows:
This section covers how to select one of the three embedded databases that Spring
supports. It includes the following topics:
* <<jdbc-embedded-database-using-HSQL>>
* <<jdbc-embedded-database-using-H2>>
* <<jdbc-embedded-database-using-Derby>>
* xref:data-access/jdbc/embedded-database-support.adoc#jdbc-embedded-database-using-HSQL[Using HSQL]
* xref:data-access/jdbc/embedded-database-support.adoc#jdbc-embedded-database-using-H2[Using H2]
* xref:data-access/jdbc/embedded-database-support.adoc#jdbc-embedded-database-using-Derby[Using Derby]
[[jdbc-embedded-database-using-HSQL]]
=== Using HSQL
@@ -163,9 +163,9 @@ Embedded databases provide a lightweight way to test data access code. The next
data access integration test template that uses an embedded database. Using such a template
can be useful for one-offs when the embedded database does not need to be reused across test
classes. However, if you wish to create an embedded database that is shared within a test suite,
consider using the <<testing.adoc#testcontext-framework, Spring TestContext Framework>> and
consider using the xref:testing/testcontext-framework.adoc[Spring TestContext Framework] and
configuring the embedded database as a bean in the Spring `ApplicationContext` as described
in <<jdbc-embedded-database-xml>> and <<jdbc-embedded-database-java>>. The following listing
in xref:data-access/jdbc/embedded-database-support.adoc#jdbc-embedded-database-xml[Creating an Embedded Database by Using Spring XML] and xref:data-access/jdbc/embedded-database-support.adoc#jdbc-embedded-database-java[Creating an Embedded Database Programmatically]. The following listing
shows the test template:
[source,java,indent=0,subs="verbatim,quotes",role="primary"]

4
framework-docs/modules/ROOT/pages/data-access/jdbc/object.adoc
View File

@@ -10,7 +10,7 @@ procedures and run update, delete, and insert statements.
[NOTE]
====
Many Spring developers believe that the various RDBMS operation classes described below
(with the exception of the <<jdbc-StoredProcedure, `StoredProcedure`>> class) can often
(with the exception of the xref:data-access/jdbc/object.adoc#jdbc-StoredProcedure[`StoredProcedure`] class) can often
be replaced with straight `JdbcTemplate` calls. Often, it is simpler to write a DAO
method that calls a method on a `JdbcTemplate` directly (as opposed to
encapsulating a query as a full-blown class).
@@ -236,7 +236,7 @@ The SQL type is specified using the `java.sql.Types` constants.
The first line (with the `SqlParameter`) declares an IN parameter. You can use IN parameters
both for stored procedure calls and for queries using the `SqlQuery` and its
subclasses (covered in <<jdbc-SqlQuery>>).
subclasses (covered in xref:data-access/jdbc/object.adoc#jdbc-SqlQuery[Understanding `SqlQuery`]).
The second line (with the `SqlOutParameter`) declares an `out` parameter to be used in the
stored procedure call. There is also an `SqlInOutParameter` for `InOut` parameters

10
framework-docs/modules/ROOT/pages/data-access/jdbc/packages.adoc
View File

@@ -8,19 +8,19 @@ various callback interfaces, plus a variety of related classes. A subpackage nam
`org.springframework.jdbc.core.simple` contains the `SimpleJdbcInsert` and
`SimpleJdbcCall` classes. Another subpackage named
`org.springframework.jdbc.core.namedparam` contains the `NamedParameterJdbcTemplate`
class and the related support classes. See <<jdbc-core>>, <<jdbc-advanced-jdbc>>, and
<<jdbc-simple-jdbc>>.
class and the related support classes. See xref:data-access/jdbc/core.adoc[Using the JDBC Core Classes to Control Basic JDBC Processing and Error Handling], xref:data-access/jdbc/advanced.adoc[JDBC Batch Operations], and
xref:data-access/jdbc/simple.adoc[Simplifying JDBC Operations with the `SimpleJdbc` Classes].
* `datasource`: The `org.springframework.jdbc.datasource` package contains a utility class for easy
`DataSource` access and various simple `DataSource` implementations that you can use for
testing and running unmodified JDBC code outside of a Jakarta EE container. A subpackage
named `org.springfamework.jdbc.datasource.embedded` provides support for creating
embedded databases by using Java database engines, such as HSQL, H2, and Derby. See
<<jdbc-connections>> and <<jdbc-embedded-database-support>>.
xref:data-access/jdbc/connections.adoc[Controlling Database Connections] and xref:data-access/jdbc/embedded-database-support.adoc[Embedded Database Support].
* `object`: The `org.springframework.jdbc.object` package contains classes that represent RDBMS
queries, updates, and stored procedures as thread-safe, reusable objects. See
<<jdbc-object>>. This approach is modeled by JDO, although objects returned by queries
xref:data-access/jdbc/object.adoc[Modeling JDBC Operations as Java Objects]. This approach is modeled by JDO, although objects returned by queries
are naturally disconnected from the database. This higher-level of JDBC abstraction
depends on the lower-level abstraction in the `org.springframework.jdbc.core` package.
@@ -30,7 +30,7 @@ translated to exceptions defined in the `org.springframework.dao` package. This
that code using the Spring JDBC abstraction layer does not need to implement JDBC or
RDBMS-specific error handling. All translated exceptions are unchecked, which gives you
the option of catching the exceptions from which you can recover while letting other
exceptions be propagated to the caller. See <<jdbc-SQLExceptionTranslator>>.
exceptions be propagated to the caller. See xref:data-access/jdbc/core.adoc#jdbc-SQLExceptionTranslator[Using `SQLExceptionTranslator`].

6
framework-docs/modules/ROOT/pages/data-access/jdbc/simple.adoc
View File

@@ -437,7 +437,7 @@ returned `out` parameters.
Earlier in this chapter, we described how parameters are deduced from metadata, but you can declare them
explicitly if you wish. You can do so by creating and configuring `SimpleJdbcCall` with
the `declareParameters` method, which takes a variable number of `SqlParameter` objects
as input. See the <<jdbc-params, next section>> for details on how to define an `SqlParameter`.
as input. See the xref:data-access/jdbc/simple.adoc#jdbc-params[next section] for details on how to define an `SqlParameter`.
NOTE: Explicit declarations are necessary if the database you use is not a Spring-supported
database. Currently, Spring supports metadata lookup of stored procedure calls for the
@@ -510,7 +510,7 @@ details explicitly rather than relying on metadata.
== How to Define `SqlParameters`
To define a parameter for the `SimpleJdbc` classes and also for the RDBMS operations
classes (covered in <<jdbc-object>>) you can use `SqlParameter` or one of its subclasses.
classes (covered in xref:data-access/jdbc/object.adoc[Modeling JDBC Operations as Java Objects]) you can use `SqlParameter` or one of its subclasses.
To do so, you typically specify the parameter name and SQL type in the constructor. The SQL type
is specified by using the `java.sql.Types` constants. Earlier in this chapter, we saw declarations
similar to the following:
@@ -530,7 +530,7 @@ similar to the following:
The first line with the `SqlParameter` declares an IN parameter. You can use IN parameters
for both stored procedure calls and for queries by using the `SqlQuery` and its
subclasses (covered in <<jdbc-SqlQuery>>).
subclasses (covered in xref:data-access/jdbc/object.adoc#jdbc-SqlQuery[Understanding `SqlQuery`]).
The second line (with the `SqlOutParameter`) declares an `out` parameter to be used in a
stored procedure call. There is also an `SqlInOutParameter` for `InOut` parameters

8
framework-docs/modules/ROOT/pages/data-access/orm/general.adoc
View File

@@ -2,7 +2,7 @@
= General ORM Integration Considerations
This section highlights considerations that apply to all ORM technologies.
The <<orm-hibernate>> section provides more details and also show these features and
The xref:data-access/orm/hibernate.adoc[Hibernate] section provides more details and also show these features and
configurations in a concrete context.
The major goal of Spring's ORM integration is clear application layering (with any data
@@ -31,18 +31,18 @@ interceptors for the ORM technologies.
The infrastructure provides proper resource handling and appropriate conversion of
specific API exceptions to an unchecked infrastructure exception hierarchy. Spring
introduces a DAO exception hierarchy, applicable to any data access strategy. For direct
JDBC, the `JdbcTemplate` class mentioned in a <<jdbc-JdbcTemplate, previous section>>
JDBC, the `JdbcTemplate` class mentioned in a xref:data-access/jdbc/core.adoc#jdbc-JdbcTemplate[previous section]
provides connection handling and proper conversion of `SQLException` to the
`DataAccessException` hierarchy, including translation of database-specific SQL error
codes to meaningful exception classes. For ORM technologies, see the
<<orm-exception-translation, next section>> for how to get the same exception
xref:data-access/orm/general.adoc#orm-exception-translation[next section] for how to get the same exception
translation benefits.
When it comes to transaction management, the `JdbcTemplate` class hooks in to the Spring
transaction support and supports both JTA and JDBC transactions, through respective
Spring transaction managers. For the supported ORM technologies, Spring offers Hibernate
and JPA support through the Hibernate and JPA transaction managers as well as JTA support.
For details on transaction support, see the <<transaction>> chapter.
For details on transaction support, see the xref:data-access/transaction.adoc[Transaction Management] chapter.
[[orm-exception-translation]]

8
framework-docs/modules/ROOT/pages/data-access/orm/hibernate.adoc
View File

@@ -21,7 +21,7 @@ To avoid tying application objects to hard-coded resource lookups, you can defin
resources (such as a JDBC `DataSource` or a Hibernate `SessionFactory`) as beans in the
Spring container. Application objects that need to access resources receive references
to such predefined instances through bean references, as illustrated in the DAO
definition in the <<orm-hibernate-straight, next section>>.
definition in the xref:data-access/orm/hibernate.adoc#orm-hibernate-straight[next section].
The following excerpt from an XML application context definition shows how to set up a
JDBC `DataSource` and a Hibernate `SessionFactory` on top of it:
@@ -83,7 +83,7 @@ property. On the programmatic `LocalSessionFactoryBuilder`, there is an overload
As of Spring Framework 5.1, such a native Hibernate setup can also expose a JPA
`EntityManagerFactory` for standard JPA interaction next to native Hibernate access.
See <<orm-jpa-hibernate, Native Hibernate Setup for JPA>> for details.
See xref:data-access/orm/jpa.adoc#orm-jpa-hibernate[Native Hibernate Setup for JPA] for details.
====
@@ -185,7 +185,7 @@ container by using either Java annotations or XML. This declarative transaction
lets you keep business services free of repetitive transaction demarcation code and
focus on adding business logic, which is the real value of your application.
NOTE: Before you continue, we are strongly encourage you to read <<transaction-declarative>>
NOTE: Before you continue, we are strongly encourage you to read xref:data-access/transaction/declarative.adoc[Declarative Transaction Management]
if you have not already done so.
You can annotate the service layer with `@Transactional` annotations and instruct the
@@ -447,7 +447,7 @@ to which it synchronizes (along with Spring). You have two options for doing thi
* Pass your Spring `JtaTransactionManager` bean to your Hibernate setup. The easiest
way is a bean reference into the `jtaTransactionManager` property for your
`LocalSessionFactoryBean` bean (see <<transaction-strategies-hibernate>>).
`LocalSessionFactoryBean` bean (see xref:data-access/transaction/strategies.adoc#transaction-strategies-hibernate[Hibernate Transaction Setup]).
Spring then makes the corresponding JTA strategies available to Hibernate.
* You may also configure Hibernate's JTA-related properties explicitly, in particular
"hibernate.transaction.coordinator_class", "hibernate.connection.handling_mode"

2
framework-docs/modules/ROOT/pages/data-access/orm/introduction.adoc
View File

@@ -48,7 +48,7 @@ The benefits of using the Spring Framework to create your ORM DAOs include:
aspect-oriented programming (AOP) style method interceptor either through the
`@Transactional` annotation or by explicitly configuring the transaction AOP advice in
an XML configuration file. In both cases, transaction semantics and exception handling
(rollback and so on) are handled for you. As discussed in <<orm-resource-mngmnt>>,
(rollback and so on) are handled for you. As discussed in xref:data-access/orm/general.adoc#orm-resource-mngmnt[Resource and Transaction Management],
you can also swap various transaction managers, without affecting your ORM-related code.
For example, you can swap between local transactions and JTA, with the same full services
(such as declarative transactions) available in both scenarios. Additionally,

22
framework-docs/modules/ROOT/pages/data-access/orm/jpa.adoc
View File

@@ -14,9 +14,9 @@ the underlying implementation in order to provide additional features.
The Spring JPA support offers three ways of setting up the JPA `EntityManagerFactory`
that is used by the application to obtain an entity manager.
* <<orm-jpa-setup-lemfb>>
* <<orm-jpa-setup-jndi>>
* <<orm-jpa-setup-lcemfb>>
* xref:data-access/orm/jpa.adoc#orm-jpa-setup-lemfb[Using `LocalEntityManagerFactoryBean`]
* xref:data-access/orm/jpa.adoc#orm-jpa-setup-jndi[Obtaining an EntityManagerFactory from JNDI]
* xref:data-access/orm/jpa.adoc#orm-jpa-setup-lcemfb[Using `LocalContainerEntityManagerFactoryBean`]
[[orm-jpa-setup-lemfb]]
=== Using `LocalEntityManagerFactoryBean`
@@ -92,7 +92,7 @@ NOTE: If you want to specifically configure a Hibernate setup, an immediate alte
is to set up a native Hibernate `LocalSessionFactoryBean` instead of a plain JPA
`LocalContainerEntityManagerFactoryBean`, letting it interact with JPA access code
as well as native Hibernate access code.
See <<orm-jpa-hibernate, Native Hibernate setup for JPA interaction>> for details.
See xref:data-access/orm/jpa.adoc#orm-jpa-hibernate[Native Hibernate setup for JPA interaction] for details.
The `LocalContainerEntityManagerFactoryBean` gives full control over
`EntityManagerFactory` configuration and is appropriate for environments where
@@ -172,11 +172,11 @@ Spring provides a number of `LoadTimeWeaver` implementations for various environ
letting `ClassTransformer` instances be applied only for each class loader and not
for each VM.
See the <<core.adoc#aop-aj-ltw-spring, Spring configuration>> in the AOP chapter for
See the xref:core/aop/using-aspectj.adoc#aop-aj-ltw-spring[Spring configuration] in the AOP chapter for
more insight regarding the `LoadTimeWeaver` implementations and their setup, either
generic or customized to various platforms (such as Tomcat, JBoss and WebSphere).
As described in <<core.adoc#aop-aj-ltw-spring, Spring configuration>>, you can configure
As described in xref:core/aop/using-aspectj.adoc#aop-aj-ltw-spring[Spring configuration], you can configure
a context-wide `LoadTimeWeaver` by using the `@EnableLoadTimeWeaving` annotation or the
`context:load-time-weaver` XML element. Such a global weaver is automatically picked up
by all JPA `LocalContainerEntityManagerFactoryBean` instances. The following example
@@ -452,7 +452,7 @@ a non-invasiveness perspective and can feel more natural to JPA developers.
[[orm-jpa-tx]]
== Spring-driven JPA transactions
NOTE: We strongly encourage you to read <<transaction-declarative>>, if you have not
NOTE: We strongly encourage you to read xref:data-access/transaction/declarative.adoc[Declarative Transaction Management], if you have not
already done so, to get more detailed coverage of Spring's declarative transaction support.
The recommended strategy for JPA is local transactions through JPA's native transaction
@@ -464,12 +464,12 @@ Spring JPA also lets a configured `JpaTransactionManager` expose a JPA transacti
to JDBC access code that accesses the same `DataSource`, provided that the registered
`JpaDialect` supports retrieval of the underlying JDBC `Connection`.
Spring provides dialects for the EclipseLink and Hibernate JPA implementations.
See the <<orm-jpa-dialect, next section>> for details on the `JpaDialect` mechanism.
See the xref:data-access/orm/jpa.adoc#orm-jpa-dialect[next section] for details on the `JpaDialect` mechanism.
NOTE: As an immediate alternative, Spring's native `HibernateTransactionManager` is capable
of interacting with JPA access code, adapting to several Hibernate specifics and providing
JDBC interaction. This makes particular sense in combination with `LocalSessionFactoryBean`
setup. See <<orm-jpa-hibernate, Native Hibernate Setup for JPA Interaction>> for details.
setup. See xref:data-access/orm/jpa.adoc#orm-jpa-hibernate[Native Hibernate Setup for JPA Interaction] for details.
[[orm-jpa-dialect]]
@@ -529,7 +529,7 @@ Hibernate 5.0 but not any more in Hibernate 5.1+. For a JTA setup, make sure to
your persistence unit transaction type as "JTA". 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 related notes.
See xref:data-access/orm/hibernate.adoc#orm-hibernate-invalid-jdbc-access-error[Spurious Application Server Warnings with Hibernate] for related notes.
* Alternatively, consider obtaining the `EntityManagerFactory` from your application
server itself (that is, through a JNDI lookup instead of a locally declared
@@ -565,7 +565,7 @@ seamlessly integrating with `@Bean` style configuration (no `FactoryBean` involv
====
`LocalSessionFactoryBean` and `LocalSessionFactoryBuilder` support background
bootstrapping, just as the JPA `LocalContainerEntityManagerFactoryBean` does.
See <<orm-jpa-setup-background, Background Bootstrapping>> for an introduction.
See xref:data-access/orm/jpa.adoc#orm-jpa-setup-background[Background Bootstrapping] for an introduction.
On `LocalSessionFactoryBean`, this is available through the `bootstrapExecutor`
property. On the programmatic `LocalSessionFactoryBuilder`, an overloaded

14
framework-docs/modules/ROOT/pages/data-access/oxm.adoc
View File

@@ -18,9 +18,9 @@ stream, or a SAX handler.
Some of the benefits of using Spring for your O/X mapping needs are:
* <<oxm-ease-of-configuration>>
* <<oxm-consistent-interfaces>>
* <<oxm-consistent-exception-hierarchy>>
* xref:data-access/oxm.adoc#oxm-ease-of-configuration[Ease of configuration]
* xref:data-access/oxm.adoc#oxm-consistent-interfaces[Consistent Interfaces]
* xref:data-access/oxm.adoc#oxm-consistent-exception-hierarchy[Consistent Exception Hierarchy]
[[oxm-ease-of-configuration]]
@@ -57,7 +57,7 @@ These runtime exceptions wrap the original exception so that no information is l
[[oxm-marshaller-unmarshaller]]
== `Marshaller` and `Unmarshaller`
As stated in the <<oxm-introduction, introduction>>, a marshaller serializes an object
As stated in the xref:data-access/oxm.adoc#oxm-introduction[introduction], a marshaller serializes an object
to XML, and an unmarshaller deserializes XML stream to an object. This section describes
the two Spring interfaces used for this purpose.
@@ -332,8 +332,8 @@ preamble of the XML configuration file. The following example shows how to do so
The schema makes the following elements available:
* <<oxm-jaxb2-xsd, `jaxb2-marshaller`>>
* <<oxm-jibx-xsd, `jibx-marshaller`>>
* xref:data-access/oxm.adoc#oxm-jaxb2-xsd[`jaxb2-marshaller`]
* xref:data-access/oxm.adoc#oxm-jibx-xsd[`jibx-marshaller`]
Each tag is explained in its respective marshaller's section. As an example, though,
the configuration of a JAXB2 marshaller might resemble the following:
@@ -353,7 +353,7 @@ The JAXB binding compiler translates a W3C XML Schema into one or more Java clas
generate a schema from annotated Java classes.
Spring supports the JAXB 2.0 API as XML marshalling strategies, following the
`Marshaller` and `Unmarshaller` interfaces described in <<oxm-marshaller-unmarshaller>>.
`Marshaller` and `Unmarshaller` interfaces described in xref:data-access/oxm.adoc#oxm-marshaller-unmarshaller[`Marshaller` and `Unmarshaller`].
The corresponding integration classes reside in the `org.springframework.oxm.jaxb`
package.

28
framework-docs/modules/ROOT/pages/data-access/r2dbc.adoc
View File

@@ -11,11 +11,11 @@ specification effort to standardize access to SQL databases using reactive patte
The Spring Framework's R2DBC abstraction framework consists of two different packages:
* `core`: The `org.springframework.r2dbc.core` package contains the `DatabaseClient`
class plus a variety of related classes. See <<r2dbc-core>>.
class plus a variety of related classes. See xref:data-access/r2dbc.adoc#r2dbc-core[Using the R2DBC Core Classes to Control Basic R2DBC Processing and Error Handling].
* `connection`: The `org.springframework.r2dbc.connection` package contains a utility class
for easy `ConnectionFactory` access and various simple `ConnectionFactory` implementations
that you can use for testing and running unmodified R2DBC. See <<r2dbc-connections>>.
that you can use for testing and running unmodified R2DBC. See xref:data-access/r2dbc.adoc#r2dbc-connections[Controlling Database Connections].
[[r2dbc-core]]
@@ -24,12 +24,12 @@ that you can use for testing and running unmodified R2DBC. See <<r2dbc-connectio
This section covers how to use the R2DBC core classes to control basic R2DBC processing,
including error handling. It includes the following topics:
* <<r2dbc-DatabaseClient>>
* <<r2dbc-DatabaseClient-examples-statement>>
* <<r2dbc-DatabaseClient-examples-query>>
* <<r2dbc-DatabaseClient-examples-update>>
* <<r2dbc-DatabaseClient-filter>>
* <<r2dbc-auto-generated-keys>>
* xref:data-access/r2dbc.adoc#r2dbc-DatabaseClient[Using `DatabaseClient`]
* xref:data-access/r2dbc.adoc#r2dbc-DatabaseClient-examples-statement[Executing Statements]
* xref:data-access/r2dbc.adoc#r2dbc-DatabaseClient-examples-query[Querying (`SELECT`)]
* xref:data-access/r2dbc.adoc#r2dbc-DatabaseClient-examples-update[Updating (`INSERT`, `UPDATE`, and `DELETE`) with `DatabaseClient`]
* xref:data-access/r2dbc.adoc#r2dbc-DatabaseClient-filter[Statement Filters]
* xref:data-access/r2dbc.adoc#r2dbc-auto-generated-keys[Retrieving Auto-generated Keys]
[[r2dbc-DatabaseClient]]
=== Using `DatabaseClient`
@@ -44,7 +44,7 @@ SQL and extract results. The `DatabaseClient` class:
* Update statements and stored procedure calls
* Performs iteration over `Result` instances
* Catches R2DBC exceptions and translates them to the generic, more informative, exception
hierarchy defined in the `org.springframework.dao` package. (See <<dao-exceptions>>.)
hierarchy defined in the `org.springframework.dao` package. (See xref:data-access/dao.adoc#dao-exceptions[Consistent Exception Hierarchy].)
The client has a functional, fluent API using reactive types for declarative composition.
@@ -543,11 +543,11 @@ requests the generated key for the desired column.
This section covers:
* <<r2dbc-ConnectionFactory>>
* <<r2dbc-ConnectionFactoryUtils>>
* <<r2dbc-SingleConnectionFactory>>
* <<r2dbc-TransactionAwareConnectionFactoryProxy>>
* <<r2dbc-R2dbcTransactionManager>>
* xref:data-access/r2dbc.adoc#r2dbc-ConnectionFactory[Using `ConnectionFactory`]
* xref:data-access/r2dbc.adoc#r2dbc-ConnectionFactoryUtils[Using `ConnectionFactoryUtils`]
* xref:data-access/r2dbc.adoc#r2dbc-SingleConnectionFactory[Using `SingleConnectionFactory`]
* xref:data-access/r2dbc.adoc#r2dbc-TransactionAwareConnectionFactoryProxy[Using `TransactionAwareConnectionFactoryProxy`]
* xref:data-access/r2dbc.adoc#r2dbc-R2dbcTransactionManager[Using `R2dbcTransactionManager`]
[[r2dbc-ConnectionFactory]]

22
framework-docs/modules/ROOT/pages/data-access/transaction.adoc
View File

@@ -7,34 +7,34 @@ management that delivers the following benefits:
* A consistent programming model across different transaction APIs, such as Java
Transaction API (JTA), JDBC, Hibernate, and the Java Persistence API (JPA).
* Support for <<transaction-declarative, declarative transaction management>>.
* A simpler API for <<transaction-programmatic, programmatic>> transaction management
* Support for xref:data-access/transaction/declarative.adoc[declarative transaction management].
* A simpler API for xref:data-access/transaction/programmatic.adoc[programmatic] transaction management
than complex transaction APIs, such as JTA.
* Excellent integration with Spring's data access abstractions.
The following sections describe the Spring Framework's transaction features and
technologies:
* <<transaction-motivation, Advantages of the Spring Framework's transaction support
model>> describes why you would use the Spring Framework's transaction abstraction
* xref:data-access/transaction/motivation.adoc[Advantages of the Spring Framework's transaction support model]
describes why you would use the Spring Framework's transaction abstraction
instead of EJB Container-Managed Transactions (CMT) or choosing to drive local
transactions through a proprietary API, such as Hibernate.
* <<transaction-strategies, Understanding the Spring Framework transaction abstraction>>
* xref:data-access/transaction/strategies.adoc[Understanding the Spring Framework transaction abstraction]
outlines the core classes and describes how to configure and obtain `DataSource`
instances from a variety of sources.
* <<tx-resource-synchronization, Synchronizing resources with transactions>> describes
* xref:data-access/transaction/tx-resource-synchronization.adoc[Synchronizing resources with transactions] describes
how the application code ensures that resources are created, reused, and cleaned up
properly.
* <<transaction-declarative, Declarative transaction management>> describes support for
* xref:data-access/transaction/declarative.adoc[Declarative transaction management] describes support for
declarative transaction management.
* <<transaction-programmatic, Programmatic transaction management>> covers support for
* xref:data-access/transaction/programmatic.adoc[Programmatic transaction management] covers support for
programmatic (that is, explicitly coded) transaction management.
* <<transaction-event, Transaction bound event>> describes how you could use application
* xref:data-access/transaction/event.adoc[Transaction bound event] describes how you could use application
events within a transaction.
The chapter also includes discussions of best practices,
<<transaction-application-server-integration, application server integration>>,
and <<transaction-solutions-to-common-problems, solutions to common problems>>.
xref:data-access/transaction/application-server-integration.adoc[application server integration],
and xref:data-access/transaction/solutions-to-common-problems.adoc[solutions to common problems].

2
framework-docs/modules/ROOT/pages/data-access/transaction/declarative.adoc
View File

@@ -22,7 +22,7 @@ necessary. The differences between the two types of transaction management are:
* You can apply the Spring Framework declarative transaction management to any class,
not merely special classes such as EJBs.
* The Spring Framework offers declarative
<<transaction-declarative-rolling-back, rollback rules>>, a feature with no EJB
xref:data-access/transaction/declarative/rolling-back.adoc[rollback rules], a feature with no EJB
equivalent. Both programmatic and declarative support for rollback rules is provided.
* The Spring Framework lets you customize transactional behavior by using AOP.
For example, you can insert custom behavior in the case of transaction rollback. You

24
framework-docs/modules/ROOT/pages/data-access/transaction/declarative/annotations.adoc
View File

@@ -70,7 +70,7 @@ Consider the following class definition:
Used at the class level as above, the annotation indicates a default for all methods of
the declaring class (as well as its subclasses). Alternatively, each method can be
annotated individually. See <<transaction-declarative-annotations-method-visibility>> for
annotated individually. See xref:data-access/transaction/declarative/annotations.adoc#transaction-declarative-annotations-method-visibility[null] for
further details on which methods Spring considers transactional. Note that a class-level
annotation does not apply to ancestor classes up the class hierarchy; in such a scenario,
inherited methods need to be locally redeclared in order to participate in a
@@ -182,7 +182,7 @@ programming arrangements as the following listing shows:
----
Note that there are special considerations for the returned `Publisher` with regards to
Reactive Streams cancellation signals. See the <<tx-prog-operator-cancel>> section under
Reactive Streams cancellation signals. See the xref:data-access/transaction/programmatic.adoc#tx-prog-operator-cancel[Cancel Signals] section under
"Using the TransactionalOperator" for more details.
@@ -221,7 +221,7 @@ Note, however, that transactional methods in interface-based proxies must always
----
The _Spring TestContext Framework_ supports non-private `@Transactional` test methods by
default. See <<testing.adoc#testcontext-tx,Transaction Management>> in the testing
default. See xref:testing/testcontext-framework/tx.adoc[Transaction Management] in the testing
chapter for examples.
====
@@ -276,7 +276,7 @@ is modified) to support `@Transactional` runtime behavior on any kind of method.
affected classes with Spring's AspectJ transaction aspect, modifying the target class
byte code to apply to any kind of method call. AspectJ weaving requires
`spring-aspects.jar` in the classpath as well as having load-time weaving (or compile-time
weaving) enabled. (See <<core.adoc#aop-aj-ltw-spring, Spring configuration>>
weaving) enabled. (See xref:core/aop/using-aspectj.adoc#aop-aj-ltw-spring[Spring configuration]
for details on how to set up load-time weaving.)
| `proxy-target-class`
@@ -286,7 +286,7 @@ is modified) to support `@Transactional` runtime behavior on any kind of method.
for classes annotated with the `@Transactional` annotation. If the
`proxy-target-class` attribute is set to `true`, class-based proxies are created.
If `proxy-target-class` is `false` or if the attribute is omitted, then standard JDK
interface-based proxies are created. (See <<core.adoc#aop-proxying, Proxying Mechanisms>>
interface-based proxies are created. (See xref:core/aop/proxying.adoc[Proxying Mechanisms]
for a detailed examination of the different proxy types.)
| `order`
@@ -294,7 +294,7 @@ is modified) to support `@Transactional` runtime behavior on any kind of method.
| `Ordered.LOWEST_PRECEDENCE`
| Defines the order of the transaction advice that is applied to beans annotated with
`@Transactional`. (For more information about the rules related to ordering of AOP
advice, see <<core.adoc#aop-ataspectj-advice-ordering, Advice Ordering>>.)
advice, see xref:core/aop/ataspectj/advice.adoc#aop-ataspectj-advice-ordering[Advice Ordering].)
No specified ordering means that the AOP subsystem determines the order of the advice.
|===
@@ -307,14 +307,14 @@ NOTE: The `proxy-target-class` attribute controls what type of transactional pro
created for classes annotated with the `@Transactional` annotation. If
`proxy-target-class` is set to `true`, class-based proxies are created. If
`proxy-target-class` is `false` or if the attribute is omitted, standard JDK
interface-based proxies are created. (See <<core.adoc#aop-proxying, Proxying Mechanisms>>
interface-based proxies are created. (See xref:core/aop/proxying.adoc[Proxying Mechanisms]
for a discussion of the different proxy types.)
NOTE: `@EnableTransactionManagement` and `<tx:annotation-driven/>` look for
`@Transactional` only on beans in the same application context in which they are defined.
This means that, if you put annotation-driven configuration in a `WebApplicationContext`
for a `DispatcherServlet`, it checks for `@Transactional` beans only in your controllers
and not in your services. See <<web.adoc#mvc-servlet, MVC>> for more information.
and not in your services. See xref:web/webmvc/mvc-servlet.adoc[MVC] for more information.
The most derived location takes precedence when evaluating the transactional settings
for a method. In the case of the following example, the `DefaultFooService` class is
@@ -382,7 +382,7 @@ properties of the `@Transactional` annotation:
|===
| Property| Type| Description
| <<tx-multiple-tx-mgrs-with-attransactional,value>>
| xref:data-access/transaction/declarative/annotations.adoc#tx-multiple-tx-mgrs-with-attransactional[value]
| `String`
| Optional qualifier that specifies the transaction manager to be used.
@@ -394,7 +394,7 @@ properties of the `@Transactional` annotation:
| Array of `String` labels to add an expressive description to the transaction.
| Labels may be evaluated by transaction managers to associate implementation-specific behavior with the actual transaction.
| <<tx-propagation,propagation>>
| xref:data-access/transaction/declarative/tx-propagation.adoc[propagation]
| `enum`: `Propagation`
| Optional propagation setting.
@@ -431,7 +431,7 @@ properties of the `@Transactional` annotation:
| Optional array of exception name patterns that must not cause rollback.
|===
TIP: See <<transaction-declarative-rollback-rules, Rollback rules>> for further details
TIP: See xref:data-access/transaction/declarative/rolling-back.adoc#transaction-declarative-rollback-rules[Rollback rules] for further details
on rollback rule semantics, patterns, and warnings regarding possible unintentional
matches for pattern-based rollback rules.
@@ -523,7 +523,7 @@ is still used if no specifically qualified `TransactionManager` bean is found.
== Custom Composed Annotations
If you find you repeatedly use the same attributes with `@Transactional` on many different
methods, <<core.adoc#beans-meta-annotations, Spring's meta-annotation support>> lets you
methods, xref:core/beans/classpath-scanning.adoc#beans-meta-annotations[Spring's meta-annotation support] lets you
define custom composed annotations for your specific use cases. For example, consider the
following annotation definitions:

4
framework-docs/modules/ROOT/pages/data-access/transaction/declarative/applying-more-than-just-tx-advice.adoc
View File

@@ -13,7 +13,7 @@ When you invoke the `updateFoo(Foo)` method, you want to see the following actio
* The profiling aspect reports the exact duration of the whole transactional method invocation.
NOTE: This chapter is not concerned with explaining AOP in any great detail (except as it
applies to transactions). See <<core.adoc#aop,AOP>> for detailed coverage of the AOP
applies to transactions). See xref:core/aop.adoc[AOP] for detailed coverage of the AOP
configuration and AOP in general.
The following code shows the simple profiling aspect discussed earlier:
@@ -95,7 +95,7 @@ The following code shows the simple profiling aspect discussed earlier:
The ordering of advice
is controlled through the `Ordered` interface. For full details on advice ordering, see
<<core.adoc#aop-ataspectj-advice-ordering,Advice ordering>>.
xref:core/aop/ataspectj/advice.adoc#aop-ataspectj-advice-ordering[Advice ordering].
The following configuration creates a `fooService` bean that has profiling and
transactional aspects applied to it in the desired order:

10
framework-docs/modules/ROOT/pages/data-access/transaction/declarative/aspectj.adoc
View File

@@ -10,12 +10,12 @@ and then link (weave) your application with the
manager. You can use the Spring Framework's IoC container to take care of
dependency-injecting the aspect. The simplest way to configure the transaction
management aspect is to use the `<tx:annotation-driven/>` element and specify the `mode`
attribute to `aspectj` as described in <<transaction-declarative-annotations>>. Because
attribute to `aspectj` as described in xref:data-access/transaction/declarative/annotations.adoc[Using `@Transactional`]. Because
we focus here on applications that run outside of a Spring container, we show
you how to do it programmatically.
NOTE: Prior to continuing, you may want to read <<transaction-declarative-annotations>> and
<<core.adoc#aop, AOP>> respectively.
NOTE: Prior to continuing, you may want to read xref:data-access/transaction/declarative/annotations.adoc[Using `@Transactional`] and
xref:core/aop.adoc[AOP] respectively.
The following example shows how to create a transaction manager and configure the
`AnnotationTransactionAspect` to use it:
@@ -53,8 +53,8 @@ regardless of visibility.
To weave your applications with the `AnnotationTransactionAspect`, you must either build
your application with AspectJ (see the
https://www.eclipse.org/aspectj/doc/released/devguide/index.html[AspectJ Development
Guide]) or use load-time weaving. See <<core.adoc#aop-aj-ltw,Load-time weaving with
AspectJ in the Spring Framework>> for a discussion of load-time weaving with AspectJ.
Guide]) or use load-time weaving. See xref:core/aop/using-aspectj.adoc#aop-aj-ltw[Load-time weaving with AspectJ in the Spring Framework]
for a discussion of load-time weaving with AspectJ.

4
framework-docs/modules/ROOT/pages/data-access/transaction/declarative/first-example.adoc
View File

@@ -187,7 +187,7 @@ advisor. The result indicates that, at the execution of a `fooServiceOperation`,
the advice defined by `txAdvice` is run.
The expression defined within the `<aop:pointcut/>` element is an AspectJ pointcut
expression. See <<core.adoc#aop, the AOP section>> for more details on pointcut
expression. See xref:core/aop.adoc[the AOP section] for more details on pointcut
expressions in Spring.
A common requirement is to make an entire service layer transactional. The best way to
@@ -203,7 +203,7 @@ service layer. The following example shows how to do so:
----
NOTE: In the preceding example, it is assumed that all your service interfaces are defined
in the `x.y.service` package. See <<core.adoc#aop, the AOP section>> for more details.
in the `x.y.service` package. See xref:core/aop.adoc[the AOP section] for more details.
Now that we have analyzed the configuration, you may be asking yourself,
"What does all this configuration actually do?"

4
framework-docs/modules/ROOT/pages/data-access/transaction/declarative/rolling-back.adoc
View File

@@ -6,7 +6,7 @@ classes, typically service layer classes, declaratively in your application. Thi
describes how you can control the rollback of transactions in a simple, declarative
fashion in XML configuration. For details on controlling rollback semantics declaratively
with the `@Transactional` annotation, see
<<transaction-declarative-attransactional-settings>>.
xref:data-access/transaction/declarative/annotations.adoc#transaction-declarative-attransactional-settings[`@Transactional` Settings].
The recommended way to indicate to the Spring Framework's transaction infrastructure
that a transaction's work is to be rolled back is to throw an `Exception` from code that
@@ -51,7 +51,7 @@ thrown, and the rules are based on exception types or exception patterns.
Rollback rules may be configured in XML via the `rollback-for` and `no-rollback-for`
attributes, which allow rules to be defined as patterns. When using
<<transaction-declarative-attransactional-settings,`@Transactional`>>, rollback rules may
xref:data-access/transaction/declarative/annotations.adoc#transaction-declarative-attransactional-settings[`@Transactional`], rollback rules may
be configured via the `rollbackFor`/`noRollbackFor` and
`rollbackForClassName`/`noRollbackForClassName` attributes, which allow rules to be
defined based on exception types or patterns, respectively.

4
framework-docs/modules/ROOT/pages/data-access/transaction/declarative/tx-decl-explained.adoc
View File

@@ -9,13 +9,13 @@ infrastructure in the context of transaction-related issues.
The most important concepts to grasp with regard to the Spring Framework's declarative
transaction support are that this support is enabled
<<core.adoc#aop-understanding-aop-proxies, via AOP proxies>> and that the transactional
xref:core/aop/proxying.adoc#aop-understanding-aop-proxies[via AOP proxies] and that the transactional
advice is driven by metadata (currently XML- or annotation-based). The combination of AOP
with transactional metadata yields an AOP proxy that uses a `TransactionInterceptor` in
conjunction with an appropriate `TransactionManager` implementation to drive transactions
around method invocations.
NOTE: Spring AOP is covered in <<core.adoc#aop, the AOP section>>.
NOTE: Spring AOP is covered in xref:core/aop.adoc[the AOP section].
Spring Framework's `TransactionInterceptor` provides transaction management for
imperative and reactive programming models. The interceptor detects the desired flavor of

2
framework-docs/modules/ROOT/pages/data-access/transaction/declarative/txadvice-settings.adoc
View File

@@ -4,7 +4,7 @@
This section summarizes the various transactional settings that you can specify by using
the `<tx:advice/>` tag. The default `<tx:advice/>` settings are:
* The <<tx-propagation, propagation setting>> is `REQUIRED.`
* The xref:data-access/transaction/declarative/tx-propagation.adoc[propagation setting] is `REQUIRED.`
* The isolation level is `DEFAULT.`
* The transaction is read-write.
* The transaction timeout defaults to the default timeout of the underlying transaction

4
framework-docs/modules/ROOT/pages/data-access/transaction/programmatic.adoc
View File

@@ -139,7 +139,7 @@ Code within the callback can roll the transaction back by calling the
You can specify transaction settings (such as the propagation mode, the isolation level,
the timeout, and so forth) on the `TransactionTemplate` either programmatically or in
configuration. By default, `TransactionTemplate` instances have the
<<transaction-declarative-txadvice-settings,default transactional settings>>. The
xref:data-access/transaction/declarative/txadvice-settings.adoc[default transactional settings]. The
following example shows the programmatic customization of the transactional settings for
a specific `TransactionTemplate:`
@@ -302,7 +302,7 @@ the full output must be consumed to allow the transaction to complete.
You can specify transaction settings (such as the propagation mode, the isolation level,
the timeout, and so forth) for the `TransactionalOperator`. By default,
`TransactionalOperator` instances have
<<transaction-declarative-txadvice-settings,default transactional settings>>. The
xref:data-access/transaction/declarative/txadvice-settings.adoc[default transactional settings]. The
following example shows customization of the transactional settings for a specific
`TransactionalOperator:`

2
framework-docs/modules/ROOT/pages/data-access/transaction/solutions-to-common-problems.adoc
View File

@@ -12,7 +12,7 @@ transactional technologies and requirements. Used properly, the Spring Framework
provides a straightforward and portable abstraction. If you use global
transactions, you must use the
`org.springframework.transaction.jta.JtaTransactionManager` class (or an
<<transaction-application-server-integration,application server-specific subclass>> of
xref:data-access/transaction/application-server-integration.adoc[application server-specific subclass] of
it) for all your transactional operations. Otherwise, the transaction infrastructure
tries to perform local transactions on such resources as container `DataSource`
instances. Such local transactions do not make sense, and a good application server

8
framework-docs/modules/ROOT/pages/data-access/transaction/strategies.adoc
View File

@@ -22,7 +22,7 @@ transaction management. The following listing shows the definition of the
----
This is primarily a service provider interface (SPI), although you can use it
<<transaction-programmatic-ptm, programmatically>> from your application code. Because
xref:data-access/transaction/programmatic.adoc#transaction-programmatic-ptm[programmatically] from your application code. Because
`PlatformTransactionManager` is an interface, it can be easily mocked or stubbed as
necessary. It is not tied to a lookup strategy, such as JNDI.
`PlatformTransactionManager` implementations are defined like any other object (or bean)
@@ -63,7 +63,7 @@ listing shows the transaction strategy defined by
----
The reactive transaction manager is primarily a service provider interface (SPI),
although you can use it <<transaction-programmatic-rtm, programmatically>> from your
although you can use it xref:data-access/transaction/programmatic.adoc#transaction-programmatic-rtm[programmatically] from your
application code. Because `ReactiveTransactionManager` is an interface, it can be easily
mocked or stubbed as necessary.
@@ -75,7 +75,7 @@ The `TransactionDefinition` interface specifies:
example, code can continue running in the existing transaction (the common case), or
the existing transaction can be suspended and a new transaction created. Spring
offers all of the transaction propagation options familiar from EJB CMT. To read
about the semantics of transaction propagation in Spring, see <<tx-propagation>>.
about the semantics of transaction propagation in Spring, see xref:data-access/transaction/declarative/tx-propagation.adoc[Transaction Propagation].
* Isolation: The degree to which this transaction is isolated from the work of other
transactions. For example, can this transaction see uncommitted writes from other
transactions?
@@ -179,7 +179,7 @@ infrastructure.
NOTE: The preceding definition of the `dataSource` bean uses the `<jndi-lookup/>` tag
from the `jee` namespace. For more information see
<<integration.adoc#integration.appendix.xsd-schemas-jee, The JEE Schema>>.
xref:integration/appendix.adoc#integration.appendix.xsd-schemas-jee[The JEE Schema].
NOTE: If you use JTA, your transaction manager definition should look the same, regardless
of what data access technology you use, be it JDBC, Hibernate JPA, or any other supported