📄 jcrespec07transact.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"><HTML LANG="en"><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1"><META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css"><META NAME="GENERATOR" CONTENT="Adobe FrameMaker 7.0/HTML Export Filter"><LINK REL="STYLESHEET" HREF="unx_unstr_styles.css" CHARSET="ISO-8859-1" TYPE="text/css"><META name="DC.TITLE" content="Runtime Environment Specification for the Java Card Platform, Version 2.2.2"><TITLE>C H A P T E R 7 - Transactions and Atomicity </TITLE></HEAD><BODY BGCOLOR="#ffffff"><DIV><div class="navbar" align="center"><table dir="LTR" summary="Navigation bar, includes the book title and navigation buttons" width=100% cellpadding="0" cellspacing="0" border="0"><colgroup span="2" width="100%"><col id="1" span="1" width="50%"><col id="2" span="1" width="50%"><tr bgcolor="#cccccc"><td class="navbartitle" align=left rowspan="1" colspan="1" abbr="ChapTitle"> Runtime Environment Specification for the Java Card Platform, Version 2.2.2</td><td valign="top" align="right" rowspan="1" colspan="1" abbr="NavButtons"><a href="index.html"><img src="shared/toc01.gif" title="Table Of Contents" alt="Table Of Contents" width="30" height="26" border="0"></a><a href="JCRESpec06firewall.html"><img src="shared/prev01.gif" title="Previous Chapter" alt="Previous Chapter" width="30" height="26" border="0"></a><a href="JCRESpec08rmi.html"><img src="shared/next01.gif" title="Next Chapter" alt="Next Chapter" width="30" height="26" border="0"></a><a href="ix.html"><img src="shared/index01.gif" title="Book Index" alt="Book Index" width="30" height="26" border="0"></a></td></tr></table><br><br></div></DIV><TABLE DIR="LTR" SUMMARY="Chapter Number" ABBR="ChapNum" WIDTH="100%" BORDER="0"><COLGROUP SPAN="1" WIDTH="100%"><COL ID="1" SPAN="1"><TR><TD ALIGN="right" CLASS="ChapNumber"><SPAN CLASS="ChapNumPrefix"><A NAME="pgfId-409320"></A>C H A P T E R </SPAN> <SPAN CLASS="ChapNumNum">7</SPAN><A NAME="18113"></A></TD></TR></TABLE><TABLE DIR="LTR" SUMMARY="Chapter Title" ABBR="ChapTitle" WIDTH="100%" BORDER="0"><COLGROUP SPAN="1" WIDTH="100%"><COL ID="1" SPAN="1" WIDTH="100%"><TR><TD ALIGN="right" CLASS="ChapTitle"><HR SIZE=7 NOSHADE><A NAME="pgfId-409321"></A><A NAME="49629"></A>Transactions and Atomicity </TD></TR></TABLE><P CLASS="Paragraph"><A NAME="pgfId-407091"></A>A <A NAME="marker-411724"></A><EM CLASS="Emphasis">transaction</EM> is a logical set of updates of persistent data. For example, transferring some amount of money from one account to another is a banking transaction. It is important for transactions to be atomic: Either all of the data fields are updated, or none are. The Java Card RE provides robust support for atomic transactions, so that card data is restored to its original pre-transaction state if the transaction does not complete normally. This mechanism protects against events such as power loss in the middle of a transaction, and against program errors that might cause data corruption should all steps of a transaction not complete normally. </P><H2 CLASS="Head1"><A NAME="pgfId-407099"></A><DIV><HR ALIGN=left SIZE=6 WIDTH=15% noshade></DIV>7.1 <A NAME="marker-411723"></A>Atomicity</H2><P CLASS="Paragraph"><A NAME="pgfId-407101"></A>Atomicity defines how the card handles the contents of persistent storage after a stop, failure, or fatal exception during an update of a single object or class field or array component. If power is lost during the update, the applet developer shall be able to rely on what the field or array component contains when power is restored.</P><P CLASS="Paragraph"><A NAME="pgfId-407103"></A>The Java Card platform guarantees that any update to a single persistent object or class field will be atomic. In addition, the Java Card platform provides single component level atomicity for persistent arrays. That is, if the smart card loses power during the update of a data element (field in an object, class or component of an array) that shall be preserved across CAD sessions, that data element shall be restored to its previous value.</P><P CLASS="Paragraph"><A NAME="pgfId-407105"></A>Some methods also guarantee atomicity for block updates of multiple data elements. For example, the atomicity of the <KBD CLASS="Filename-Command">Util.arrayCopy</KBD> method guarantees that either all bytes are correctly copied or else the destination array is restored to its previous byte values.</P><P CLASS="Paragraph"><A NAME="pgfId-407107"></A>An applet might not require atomicity for array updates. The <KBD CLASS="Filename-Command">Util.arrayCopyNonAtomic</KBD> method is provided for this purpose. It does not use the transaction commit buffer even when called with a transaction in progress.</P><H2 CLASS="Head1"><A NAME="pgfId-407117"></A><DIV><HR ALIGN=left SIZE=6 WIDTH=15% noshade></DIV>7.2 Transactions</H2><P CLASS="Paragraph"><A NAME="pgfId-407119"></A>An applet might need to atomically update several different fields or array components in several different objects. Either all updates take place correctly and consistently, or else all fields or components are restored to their previous values.</P><P CLASS="Paragraph"><A NAME="pgfId-407121"></A>The Java Card platform supports a transactional model in which an applet can designate the beginning of an atomic set of updates with a call to the <KBD CLASS="Filename-Command">JCSystem.beginTransaction</KBD> method. Each object update after this point is conditionally updated. The field or array component appears to be updated (reading the field or array component back yields its latest conditional value) but the update is not yet committed.</P><P CLASS="Paragraph"><A NAME="pgfId-407123"></A>When the applet calls <KBD CLASS="Filename-Command">JCSystem.commitTransaction</KBD>, all conditional updates are committed to persistent storage. If power is lost or if some other system failure occurs prior to the completion of <KBD CLASS="Filename-Command">JCSystem.commitTransaction</KBD>, all conditionally updated fields or array components are restored to their previous values. If the applet encounters an internal problem or decides to cancel the transaction, it can programmatically undo conditional updates by calling <KBD CLASS="Filename-Command">JCSystem.abortTransaction</KBD>.</P><H2 CLASS="Head1"><A NAME="pgfId-407133"></A><DIV><HR ALIGN=left SIZE=6 WIDTH=15% noshade></DIV>7.3 Transaction <A NAME="marker-411725"></A>Duration</H2><P CLASS="Paragraph"><A NAME="pgfId-407135"></A>A transaction always ends when the Java Card RE regains programmatic control upon return from the applet's <KBD CLASS="Filename-Command">select</KBD>, <KBD CLASS="Filename-Command">deselect</KBD>, <KBD CLASS="Filename-Command">process</KBD>, <KBD CLASS="Filename-Command">uninstall</KBD>, or <KBD CLASS="Filename-Command">install</KBD> methods. This is true whether a transaction ends normally, with an applet's call to <KBD CLASS="Filename-Command">commitTransaction</KBD>, or with an abortion of the transaction (either programmatically by the applet, or by default by the Java Card RE). For more details on transaction abortion, refer to <A HREF="JCRESpec07transact.html#89721" CLASS="XRef">Section 7.6, Aborting a Transaction</A>.</P><P CLASS="Paragraph"><A NAME="pgfId-407137"></A><EM CLASS="Emphasis">Transaction duration</EM> is the life of a transaction between the call to <KBD CLASS="Filename-Command">JCSystem.beginTransaction</KBD> and either a call to <KBD CLASS="Filename-Command">commitTransaction</KBD> or an abortion of the transaction. </P><H2 CLASS="Head1"><A NAME="pgfId-407145"></A><DIV><HR ALIGN=left SIZE=6 WIDTH=15% noshade></DIV>7.4 <A NAME="marker-411726"></A>Nested Transactions</H2><P CLASS="Paragraph"><A NAME="pgfId-407147"></A>The model currently assumes that nested transactions are not possible. There can be only one transaction in progress at a time. If <KBD CLASS="Filename-Command">JCSystem.beginTransaction</KBD> is called while a transaction is already in progress, a <KBD CLASS="Filename-Command">TransactionException</KBD> is thrown.</P><P CLASS="Paragraph"><A NAME="pgfId-407149"></A>The <KBD CLASS="Filename-Command">JCSystem.transactionDepth</KBD> method is provided to allow you to determine if a transaction is in progress.</P><H2 CLASS="Head1"><A NAME="pgfId-407159"></A><DIV><HR ALIGN=left SIZE=6 WIDTH=15% noshade></DIV>7.5 Tear or Reset <A NAME="marker-411727"></A>Transaction Failure</H2><P CLASS="Paragraph"><A NAME="pgfId-407161"></A>If power is lost (<A NAME="marker-411729"></A>tear) or the card is <A NAME="marker-411728"></A>reset or some other system failure occurs while a transaction is in progress, the Java Card RE shall restore to their previous values all fields and array components conditionally updated since the previous call to <KBD CLASS="Filename-Command">JCSystem.beginTransaction</KBD>. </P><P CLASS="Paragraph"><A NAME="pgfId-410290"></A>This action is performed automatically by the Java Card RE when it reinitializes the card after recovering from the power loss, reset, or failure. The Java Card RE determines which of those objects (if any) were conditionally updated, and restores them. </P><BR><HR NOSHADE SIZE=1><TABLE CLASS="TipNote" DIR="LTR" WIDTH="100%" SUMMARY="TipNote"><COLGROUP SPAN="1" WIDTH="100%"><TR ALIGN="left" VALIGN="top"><TD ROWSPAN="1" COLSPAN="1" ABBR="TipNoteText"><P CLASS="TipNote"><B CLASS="TipNote">Note - </B><A NAME="pgfId-410291"></A>The contents of an array component that is updated using the <KBD CLASS="Filename-Command">Util.arrayCopyNonAtomic</KBD> method or the <KBD CLASS="Filename-Command">Util.arrayFillNonAtomic</KBD> method while a transaction is in progress are not predictable following a tear or reset during that transaction.</P></TD></TR></TABLE>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -