root
/
spring-framework
mirror of https://github.com/spring-projects/spring-framework.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

put the definite article back in some places for Spring Framework to be consistent with common usage

This commit is contained in:
Thomas Risberg 2009-08-03 15:38:48 +00:00
parent 3d29023ef3
commit 791faf4e63
1 changed files with 48 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

95
spring-framework-reference/src/transaction.xml
View File

@ -8,9 +8,9 @@
<title>Introduction to Spring Framework transaction management</title> <title>Introduction to Spring Framework transaction management</title>
<para>Comprehensive transaction support is among the most compelling <para>Comprehensive transaction support is among the most compelling
reasons to use Spring Framework. Spring Framework provides a consistent reasons to use the Spring Framework. The Spring Framework provides a
abstraction for transaction management that delivers the following consistent abstraction for transaction management that delivers the
benefits:</para> following benefits:</para>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
@ -36,19 +36,19 @@
</listitem> </listitem>
</itemizedlist> </itemizedlist>
<para>The following sections describe Spring Framework's transaction <para>The following sections describe the Spring Framework's transaction
value-adds and technologies. (The chapter also includes discussions of value-adds and technologies. (The chapter also includes discussions of
best practices, application server integration, and solutions to common best practices, application server integration, and solutions to common
problems.)</para> problems.)</para>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para><link linkend="transaction-motivation">Advantages of Spring <para><link linkend="transaction-motivation">Advantages of the Spring
Framework's transaction support model</link> describes Framework's transaction support model</link> describes
<emphasis>why</emphasis> you would use Spring Framework's transaction <emphasis>why</emphasis> you would use the Spring Framework's
abstraction instead of EJB Container-Managed Transactions (CMT) or transaction abstraction instead of EJB Container-Managed Transactions
choosing to drive transactions through a proprietary API such as (CMT) or choosing to drive transactions through a proprietary API such
Hibernate.</para> as Hibernate.</para>
<!--The section (formerly called Motivation) does not mention Hibernate. It talks about local and global.--> <!--The section (formerly called Motivation) does not mention Hibernate. It talks about local and global.-->
</listitem> </listitem>
@ -83,13 +83,13 @@
</section> </section>
<section id="transaction-motivation"> <section id="transaction-motivation">
<title>Advantages of Spring Framework's transaction support model<!--Renamed section to make it more to the point.--></title> <title>Advantages of the Spring Framework's transaction support model<!--Renamed section to make it more to the point.--></title>
<para>Traditionally, Java EE developers have had two choices for <para>Traditionally, Java EE developers have had two choices for
transaction management: <emphasis>global</emphasis> or transaction management: <emphasis>global</emphasis> or
<emphasis>local</emphasis> transactions, both of which have profound <emphasis>local</emphasis> transactions, both of which have profound
limitations. Global and local transaction management is reviewed in the limitations. Global and local transaction management is reviewed in the
next two sections, followed by a discussion of how Spring Framework's next two sections, followed by a discussion of how the Spring Framework's
transaction management support addresses the limitations of the global and transaction management support addresses the limitations of the global and
local transaction models.</para> local transaction models.</para>
@ -148,7 +148,7 @@
<emphasis>consistent</emphasis> programming model <emphasis>in any <emphasis>consistent</emphasis> programming model <emphasis>in any
environment</emphasis>. You write your code once, and it can benefit environment</emphasis>. You write your code once, and it can benefit
from different transaction management strategies in different from different transaction management strategies in different
environments. Spring Framework provides both declarative and environments. The Spring Framework provides both declarative and
programmatic transaction management. Most users prefer declarative programmatic transaction management. Most users prefer declarative
transaction management, which is recommended in most cases.</para> transaction management, which is recommended in most cases.</para>
@ -168,7 +168,7 @@ TR: I think it's fine as is - the concepts apply to both programmatic and declar
<title>Do you need an application server for transaction <title>Do you need an application server for transaction
management?</title> management?</title>
<para>Spring Framework's transaction management support changes <para>The Spring Framework's transaction management support changes
traditional rules as to when a Java EE application requires an traditional rules as to when a Java EE application requires an
application server.</para> application server.</para>
@ -189,14 +189,14 @@ TR: I think it's fine as is - the concepts apply to both programmatic and declar
such as Java Message Service (JMS) and J2EE Connector Architecture such as Java Message Service (JMS) and J2EE Connector Architecture
(JCA).</para> (JCA).</para>
<para>Spring Framework <emphasis>gives you the choice of when to scale <para>The Spring Framework <emphasis>gives you the choice of when to
your application to a fully loaded application server</emphasis>. Gone scale your application to a fully loaded application
are the days when the only alternative to using EJB CMT or JTA was to server</emphasis>. Gone are the days when the only alternative to
write code with local transactions such as those on JDBC connections, using EJB CMT or JTA was to write code with local transactions such as
and face a hefty rework if you need that code to run within global, those on JDBC connections, and face a hefty rework if you need that
container-managed transactions. With Spring Framework, only some of code to run within global, container-managed transactions. With the
the bean definitions in your configuration file, rather than your Spring Framework, only some of the bean definitions in your
code, needs to change.</para> configuration file, rather than your code, needs to change.</para>
<!--CLarify last sentence. Only what kind of configuration has to change? <!--CLarify last sentence. Only what kind of configuration has to change?
TR: changed to say "some of the bean definitions in your configuration file"--> TR: changed to say "some of the bean definitions in your configuration file"-->
@ -584,35 +584,35 @@ TR: I re-wrote this to match the current preferred approaches--></para>
<emphasis>non-invasive</emphasis> lightweight container.</para> <emphasis>non-invasive</emphasis> lightweight container.</para>
</note> </note>
<para>Spring Framework's declarative transaction management is made <para>The Spring Framework's declarative transaction management is made
possible with Spring aspect-oriented programming (AOP), although, as the possible with Spring aspect-oriented programming (AOP), although, as the
transactional aspects code comes with the Spring Framework distribution transactional aspects code comes with the Spring Framework distribution
and may be used in a boilerplate fashion, AOP concepts do not generally and may be used in a boilerplate fashion, AOP concepts do not generally
have to be understood to make effective use of this code.</para> have to be understood to make effective use of this code.</para>
<para>Spring Framework's declarative transaction management is similar to <para>The Spring Framework's declarative transaction management is similar
EJB CMT in that you can specify transaction behavior (or lack of it) down to EJB CMT in that you can specify transaction behavior (or lack of it)
to individual method level. It is possible to make a down to individual method level. It is possible to make a
<methodname>setRollbackOnly()</methodname> call within a transaction <methodname>setRollbackOnly()</methodname> call within a transaction
context if necessary. The differences between the two types of transaction context if necessary. The differences between the two types of transaction
management are:</para> management are:</para>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para>Unlike EJB CMT, which is tied to JTA, Spring Framework's <para>Unlike EJB CMT, which is tied to JTA, the Spring Framework's
declarative transaction management works in any environment. It can declarative transaction management works in any environment. It can
work with JTA transactions or local transactions using JDBC, JPA, work with JTA transactions or local transactions using JDBC, JPA,
Hibernate or JDO by simple adjusting the configuration files.<!--Indicate what kind of config changes? Changes to what TR: rewrote this to hoefully make it more clear--></para> Hibernate or JDO by simple adjusting the configuration files.<!--Indicate what kind of config changes? Changes to what TR: rewrote this to hoefully make it more clear--></para>
</listitem> </listitem>
<listitem> <listitem>
<para>You can apply Spring Framework declarative transaction <para>You can apply the Spring Framework declarative transaction
management to any class, not merely special classes such as management to any class, not merely special classes such as
EJBs.</para> EJBs.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Spring Framework offers declarative <link <para>The Spring Framework offers declarative <link
linkend="transaction-declarative-rolling-back"><emphasis>rollback linkend="transaction-declarative-rolling-back"><emphasis>rollback
rules</emphasis>, </link>a feature with no EJB equivalent. Both rules</emphasis>, </link>a feature with no EJB equivalent. Both
programmatic and declarative support for rollback rules is programmatic and declarative support for rollback rules is
@ -620,7 +620,7 @@ TR: I re-wrote this to match the current preferred approaches--></para>
</listitem> </listitem>
<listitem> <listitem>
<para>Spring Framework enables you to customize transactional <para>The Spring Framework enables you to customize transactional
behavior, by using AOP. For example, you can insert custom behavior in behavior, by using AOP. For example, you can insert custom behavior in
the case of transaction rollback. You can also add arbitrary advice, the case of transaction rollback. You can also add arbitrary advice,
along with the transactional advice. With EJB CMT, cannot influence along with the transactional advice. With EJB CMT, cannot influence
@ -629,7 +629,7 @@ TR: I re-wrote this to match the current preferred approaches--></para>
</listitem> </listitem>
<listitem> <listitem>
<para>Spring Framework does not support propagation of transaction <para>The Spring Framework does not support propagation of transaction
contexts across remote calls, as do high-end application servers. If contexts across remote calls, as do high-end application servers. If
you need this feature, we recommend that you use EJB. However, you need this feature, we recommend that you use EJB. However,
consider carefully before using such a feature, because normally, one consider carefully before using such a feature, because normally, one
@ -677,16 +677,16 @@ TR: I re-wrote this to match the current preferred approaches--></para>
<!--customize this so that what happens?--> <!--customize this so that what happens?-->
<section id="tx-decl-explained"> <section id="tx-decl-explained">
<title>Understanding Spring Framework's declarative transaction <title>Understanding the Spring Framework's declarative transaction
implementation</title> implementation</title>
<para>It is not sufficient to tell you simply to annotate your classes <para>It is not sufficient to tell you simply to annotate your classes
with the <interfacename>@Transactional</interfacename> annotation, add with the <interfacename>@Transactional</interfacename> annotation, add
the line (<literal>&lt;tx:annotation-driven/&gt;</literal>) to your the line (<literal>&lt;tx:annotation-driven/&gt;</literal>) to your
configuration, and then expect you to understand how it all works. This configuration, and then expect you to understand how it all works. This
section explains the inner workings of Spring Framework's declarative section explains the inner workings of the Spring Framework's
transaction infrastructure in the event of transaction-related declarative transaction infrastructure in the event of
issues.</para> transaction-related issues.</para>
<para>The most important concepts to grasp with regard to the Spring <para>The most important concepts to grasp with regard to the Spring
Framework's declarative transaction support are that this support is Framework's declarative transaction support are that this support is
@ -965,17 +965,18 @@ Exception in thread "main" java.lang.UnsupportedOperationException
control the rollback of transactions in a simple declarative control the rollback of transactions in a simple declarative
fashion.</para> fashion.</para>
<para>The recommended way to indicate to Spring Framework's transaction <para>The recommended way to indicate to the Spring Framework's
infrastructure that a transaction's work is to be rolled back is to transaction infrastructure that a transaction's work is to be rolled
throw an <exceptionname>Exception</exceptionname> from code that is back is to throw an <exceptionname>Exception</exceptionname> from code
currently executing in the context of a transaction. Spring Framework's that is currently executing in the context of a transaction. The Spring
transaction infrastructure code, in its default configuration, will Framework's transaction infrastructure code, in its default
catch any unhandled <exceptionname>Exception</exceptionname> as it configuration, will catch any unhandled
bubbles up the call stack, and mark the transaction for rollback.<!--I changed to *can be configured* because next sentence says it does not do this by default in all cases. <exceptionname>Exception</exceptionname> as it bubbles up the call
stack, and mark the transaction for rollback.<!--I changed to *can be configured* because next sentence says it does not do this by default in all cases.
TR: I changed it to *in its default configuration*--></para> TR: I changed it to *in its default configuration*--></para>
<para>However, Spring Framework's transaction infrastructure code, by <para>However, the Spring Framework's transaction infrastructure code,
default, <emphasis>only</emphasis> mark a transaction for rollback in by default, <emphasis>only</emphasis> mark a transaction for rollback in
the case of runtime, unchecked exceptions; that is, when the thrown the case of runtime, unchecked exceptions; that is, when the thrown
exception is an instance or subclass of exception is an instance or subclass of
<exceptionname>RuntimeException</exceptionname>. <exceptionname>RuntimeException</exceptionname>.
@ -1002,7 +1003,7 @@ if the underlying application server infrastructure throws an Error the transact
<para>You can also specify 'no rollback rules', if you do <para>You can also specify 'no rollback rules', if you do
<emphasis>not</emphasis> want a transaction rolled back when an <emphasis>not</emphasis> want a transaction rolled back when an
exception is thrown. The following example tells Spring Framework's exception is thrown. The following example tells the Spring Framework's
transaction infrastructure to commit the attendant transaction even in transaction infrastructure to commit the attendant transaction even in
the face of an unhandled the face of an unhandled
<exceptionname>InstrumentNotFoundException</exceptionname>.</para> <exceptionname>InstrumentNotFoundException</exceptionname>.</para>
@ -1014,7 +1015,7 @@ if the underlying application server infrastructure throws an Error the transact
&lt;/tx:attributes&gt; &lt;/tx:attributes&gt;
&lt;/tx:advice&gt;</programlisting> &lt;/tx:advice&gt;</programlisting>
<para>When Spring Framework's transaction infrastructure catches an <para>When the Spring Framework's transaction infrastructure catches an
exception and is consults configured rollback rules to determine whether exception and is consults configured rollback rules to determine whether
to mark the transaction for rollback, the <emphasis>strongest</emphasis> to mark the transaction for rollback, the <emphasis>strongest</emphasis>
matching rule wins. So in the case of the following configuration, any matching rule wins. So in the case of the following configuration, any
@ -1030,7 +1031,7 @@ if the underlying application server infrastructure throws an Error the transact
<para>You can also indicate a required rollback <para>You can also indicate a required rollback
<emphasis>programmatically</emphasis>. Although very simple, this <emphasis>programmatically</emphasis>. Although very simple, this
process is quite invasive, and tightly couples your code to Spring process is quite invasive, and tightly couples your code to the Spring
Framework's transaction infrastructure:</para> Framework's transaction infrastructure:</para>
<programlisting language="java">public void resolvePosition() { <programlisting language="java">public void resolvePosition() {
@ -2401,7 +2402,7 @@ txManager.commit(status);</programlisting>
<section id="transaction-resources"> <section id="transaction-resources">
<title>Further Resources</title> <title>Further Resources</title>
<para>For more information about Spring Framework's transaction <para>For more information about the Spring Framework's transaction
support:</para> support:</para>
<itemizedlist> <itemizedlist>