<html><head>
      <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
   <title>Chapter&nbsp;9.&nbsp; Transaction</title><link rel="stylesheet" href="css/docbook.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.72.0"><link rel="start" href="manual.html" title="Apache OpenJPA User's Guide"><link rel="up" href="jpa_overview.html" title="Part&nbsp;2.&nbsp;Java Persistence API"><link rel="prev" href="jpa_overview_em_closing.html" title="7.&nbsp; Closing"><link rel="next" href="jpa_overview_trans_local.html" title="2.&nbsp; The EntityTransaction Interface"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter&nbsp;9.&nbsp;
        Transaction
    </th></tr><tr><td width="20%" align="left"><a accesskey="p" href="jpa_overview_em_closing.html">Prev</a>&nbsp;</td><th width="60%" align="center">Part&nbsp;2.&nbsp;Java Persistence API</th><td width="20%" align="right">&nbsp;<a accesskey="n" href="jpa_overview_trans_local.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en" id="jpa_overview_trans"><div class="titlepage"><div><div><h2 class="title"><a name="jpa_overview_trans"></a>Chapter&nbsp;9.&nbsp;
        Transaction
    </h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="jpa_overview_trans.html#jpa_overview_trans_types">1. 
            Transaction Types
        </a></span></dt><dt><span class="section"><a href="jpa_overview_trans_local.html">2. 
            The EntityTransaction Interface
        </a></span></dt></dl></div><a class="indexterm" name="d0e5408"></a><p>
Transactions are critical to maintaining data integrity. They are used to group
operations into units of work that act in an all-or-nothing fashion.
Transactions have the following qualities:
    </p><div class="itemizedlist"><ul type="disc"><li><p>
            <a class="indexterm" name="d0e5419"></a>
            <a class="indexterm" name="d0e5425"></a>
<span class="emphasis"><em>Atomicity</em></span>. Atomicity refers to the all-or-nothing property
of transactions. Either every data update in the transaction completes
successfully, or they all fail, leaving the datastore in its original state. A
transaction cannot be only partially successful.
            </p></li><li><p>
            <a class="indexterm" name="d0e5437"></a>
            <a class="indexterm" name="d0e5443"></a>
<span class="emphasis"><em>Consistency</em></span>. Each transaction takes the datastore from one
consistent state to another consistent state.
            </p></li><li><p>
            <a class="indexterm" name="d0e5455"></a>
            <a class="indexterm" name="d0e5461"></a>
<span class="emphasis"><em>Isolation</em></span>. Transactions are isolated from each other. When
you are reading persistent data in one transaction, you cannot "see" the changes
that are being made to that data in other transactions. Similarly, the updates
you make in one transaction cannot conflict with updates made in concurrent
transactions. The form of conflict resolution employed depends on whether you
are using pessimistic or optimistic transactions. Both types are described later
in this chapter.
            </p></li><li><p>
            <a class="indexterm" name="d0e5473"></a>
            <a class="indexterm" name="d0e5479"></a>
<span class="emphasis"><em>Durability</em></span>. The effects of successful transactions are
durable; the updates made to persistent data last for the lifetime of the
datastore.
            </p></li></ul></div><p>
    <a class="indexterm" name="d0e5490"></a>
    <a class="indexterm" name="d0e5496"></a>
Together, these qualities are called the ACID properties of transactions. To
understand why these properties are so important to maintaining data integrity,
consider the following example:
    </p><p>
Suppose you create an application to manage bank accounts. The application
includes a method to transfer funds from one user to another, and it looks
something like this:
    </p><pre class="programlisting">
public void transferFunds(User from, User to, double amnt) {
    from.decrementAccount(amnt);
    to.incrementAccount(amnt);
}
</pre><p>
Now suppose that user Alice wants to transfer 100 dollars to user Bob. No
problem; you simply invoke your <code class="methodname">transferFunds</code> method,
supplying Alice in the <code class="literal">from</code> parameter, Bob in the <code class="literal">
to</code> parameter, and <code class="literal">100.00</code> as the <code class="literal">amnt
</code>. The first line of the method is executed, and 100 dollars is
subtracted from Alice's account. But then, something goes wrong. An unexpected
exception occurs, or the hardware fails, and your method never completes.
    </p><p>
You are left with a situation in which the 100 dollars has simply disappeared.
Thanks to the first line of your method, it is no longer in Alice's account, and
yet it was never transferred to Bob's account either. The datastore is in an
inconsistent state.
    </p><p>
The importance of transactions should now be clear. If the two lines of the
<code class="methodname">transferFunds</code> method had been placed together in a
transaction, it would be impossible for only the first line to succeed. Either
the funds would be transferred properly or they would not be transferred at all,
and an exception would be thrown. Money could never vanish into thin air, and
the data store could never get into an inconsistent state.
    </p><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="jpa_overview_trans_types"></a>1.&nbsp;
            Transaction Types
        </h2></div></div></div><a class="indexterm" name="d0e5533"></a><p>
There are two major types of transactions: pessimistic transactions and
optimistic transactions. Each type has both advantages and disadvantages.
        </p><p>
        <a class="indexterm" name="d0e5542"></a>
        <a class="indexterm" name="d0e5548"></a>
        <a class="indexterm" name="d0e5554"></a>
Pessimistic transactions generally lock the datastore records they act on,
preventing other concurrent transactions from using the same data. This avoids
conflicts between transactions, but consumes database resources. Additionally,
locking records can result in <span class="emphasis"><em>deadlock</em></span>, a situation in
which two transactions are both waiting for the other to release its locks
before completing. The results of a deadlock are datastore-dependent; usually
one transaction is forcefully rolled back after some specified timeout interval,
and an exception is thrown.
        </p><p>
        <a class="indexterm" name="d0e5565"></a>
        <a class="indexterm" name="d0e5571"></a>
This document will often use the term <span class="emphasis"><em>datastore</em></span> transaction
in place of <span class="emphasis"><em>pessimistic</em></span> transaction. This is to acknowledge
that some datastores do not support pessimistic semantics, and that the exact
meaning of a non-optimistic JPA transaction is dependent on the datastore. Most
of the time, a datastore transaction is equivalent to a pessimistic transaction.
        </p><p>
        <a class="indexterm" name="d0e5585"></a>
        <a class="indexterm" name="d0e5591"></a>
Optimistic transactions consume less resources than pessimistic/datastore
transactions, but only at the expense of reliability. Because optimistic
transactions do not lock datastore records, two transactions might change the
same persistent information at the same time, and the conflict will not be
detected until the second transaction attempts to flush or commit. At this time,
the second transaction will realize that another transaction has concurrently
modified the same records (usually through a timestamp or versioning system),
and will throw an appropriate exception. Note that optimistic transactions still
maintain data integrity; they are simply more likely to fail in heavily
concurrent situations.
        </p><p>
Despite their drawbacks, optimistic transactions are the best choice for most
applications. They offer better performance, better scalability, and lower risk
of hanging due to deadlock.
        </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
OpenJPA uses optimistic semantics by default, but supports both optimistic and
datastore transactions. OpenJPA also offers advanced locking and versioning APIs
for fine-grained control over database resource allocation and object
versioning. See <a href="ref_guide_locking.html" title="3.&nbsp; Object Locking">Section&nbsp;3, &#8220;
            Object Locking
        &#8221;</a> of the Reference Guide for 
details on locking. <a href="jpa_overview_meta_field.html#jpa_overview_meta_version" title="2.5.&nbsp; Version">Section&nbsp;2.5, &#8220;
                Version
            &#8221;</a>
of this document covers standard object versioning, while
<a href="ref_guide_mapping_jpa.html" title="7.&nbsp; Additional JPA Mappings">Section&nbsp;7, &#8220;
            Additional JPA Mappings
        &#8221;</a> of the Reference Guide discusses
additional versioning strategies available in OpenJPA.
            </p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="jpa_overview_em_closing.html">Prev</a>&nbsp;</td><td width="20%" align="center"><a accesskey="u" href="jpa_overview.html">Up</a></td><td width="40%" align="right">&nbsp;<a accesskey="n" href="jpa_overview_trans_local.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">7.&nbsp;
            Closing
        &nbsp;</td><td width="20%" align="center"><a accesskey="h" href="manual.html">Home</a></td><td width="40%" align="right" valign="top">&nbsp;2.&nbsp;
            The EntityTransaction Interface
        </td></tr></table></div></body></html>