| <html><head> |
| <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> |
| <title>Chapter 9. Transaction</title><base href="display"><link rel="stylesheet" type="text/css" href="css/docbook.css"><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"><link rel="home" href="manual.html" title="Apache OpenJPA 2.4 User's Guide"><link rel="up" href="jpa_overview.html" title="Part 2. Java Persistence API"><link rel="prev" href="jpa_overview_em_closing.html" title="9. Closing"><link rel="next" href="jpa_overview_trans_local.html" title="2. 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 9. |
| Transaction |
| </th></tr><tr><td width="20%" align="left"><a accesskey="p" href="jpa_overview_em_closing.html">Prev</a> </td><th width="60%" align="center">Part 2. Java Persistence API</th><td width="20%" align="right"> <a accesskey="n" href="jpa_overview_trans_local.html">Next</a></td></tr></table><hr></div><div class="chapter" id="jpa_overview_trans"><div class="titlepage"><div><div><h2 class="title">Chapter 9. |
| Transaction |
| </h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl class="toc"><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="d5e2793"></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 class="itemizedlist" style="list-style-type: disc; "><li class="listitem"> |
| <p> |
| <a class="indexterm" name="d5e2800"></a> |
| <a class="indexterm" name="d5e2803"></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 class="listitem"> |
| <p> |
| <a class="indexterm" name="d5e2809"></a> |
| <a class="indexterm" name="d5e2812"></a> |
| <span class="emphasis"><em>Consistency</em></span>. Each transaction takes the datastore from one |
| consistent state to another consistent state. |
| </p> |
| </li><li class="listitem"> |
| <p> |
| <a class="indexterm" name="d5e2818"></a> |
| <a class="indexterm" name="d5e2821"></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 class="listitem"> |
| <p> |
| <a class="indexterm" name="d5e2827"></a> |
| <a class="indexterm" name="d5e2830"></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="d5e2835"></a> |
| <a class="indexterm" name="d5e2838"></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" id="jpa_overview_trans_types"><div class="titlepage"><div><div><h2 class="title" style="clear: both">1. |
| Transaction Types |
| </h2></div></div></div> |
| |
| <a class="indexterm" name="d5e2854"></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="d5e2859"></a> |
| <a class="indexterm" name="d5e2862"></a> |
| <a class="indexterm" name="d5e2865"></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="d5e2870"></a> |
| <a class="indexterm" name="d5e2873"></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="d5e2879"></a> |
| <a class="indexterm" name="d5e2882"></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 class="xref" href="ref_guide_locking.html" title="3. Object Locking">Section 3, “ |
| Object Locking |
| ”</a> of the Reference Guide for |
| details on locking. <a class="xref" href="jpa_overview_meta_field.html#jpa_overview_meta_version" title="2.6. Version">Section 2.6, “ |
| Version |
| ”</a> |
| of this document covers standard object versioning, while |
| <a class="xref" href="ref_guide_mapping_jpa.html" title="7. Additional JPA Mappings">Section 7, “ |
| Additional JPA Mappings |
| ”</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> </td><td width="20%" align="center"><a accesskey="u" href="jpa_overview.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="jpa_overview_trans_local.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">9. |
| Closing |
| </td><td width="20%" align="center"><a accesskey="h" href="manual.html">Home</a></td><td width="40%" align="right" valign="top"> 2. |
| The EntityTransaction Interface |
| </td></tr></table></div></body></html> |
