[jboss-svn-commits] JBL Code SVN: r35341 - in labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US: extras and 1 other directories.
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Wed Sep 29 01:39:11 EDT 2010
Author: misty at redhat.com
Date: 2010-09-29 01:39:10 -0400 (Wed, 29 Sep 2010)
New Revision: 35341
Added:
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/Array_class.java
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/InputBuffer.java
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/InputObjectState.java
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/LockMode.java
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/LockResult.java
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/LockStore.java
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/ObjectStore.java
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/OutputBuffer.java
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/OutputObjectState.java
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/StateStatus.java
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/example_methods_for_StateManager.java
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/object_store_implementation_using_StateManager.java
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/setlock.java
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/images/multiple_object_model.png
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/images/single_object_model.png
Modified:
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Overview.xml
labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Using_TxCore.xml
Log:
Converted Using TxCore to Docbook
Modified: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Overview.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Overview.xml 2010-09-29 03:12:48 UTC (rev 35340)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Overview.xml 2010-09-29 05:39:10 UTC (rev 35341)
@@ -151,7 +151,7 @@
<term>Neither Recoverable nor Persistent</term>
<listitem>
<para>
- Bo recovery information is ever kept, nor is object activation or deactivation ever automatically attempted.
+ No recovery information is ever kept, nor is object activation or deactivation ever automatically attempted.
</para>
</listitem>
</varlistentry>
@@ -167,7 +167,8 @@
efficiency.)-->This gives the programmer the ability to decide which parts of an object’s state should be made
persistent. For example, for a spreadsheet it may not be necessary to save all entries if some values can simply
be recomputed. The <methodname>save_state</methodname> implementation for a class <classname>Example</classname>
- that has integer member variables called A, B and C might be implemented as in <xref linkend="example-save_state" />.
+ that has integer member variables called A, B and C might be implemented as in <xref linkend="example-save_state"
+ />.
</para>
<example id="example-save_state">
<title><methodname>save_state</methodname> Implementation</title>
@@ -185,8 +186,8 @@
<section>
<title>The life cycle of a Transactional Object for Java</title>
<para>
- A persistent object not in use is assumed to be held in a passive state, with its state residing in an object store
- and activated on demand. The fundamental life cycle of a persistent object in TXOJ is shown in <xref
+ A persistent object not in use is assumed to be held in a passive state, with its state residing in an object
+ store and activated on demand. The fundamental life cycle of a persistent object in TXOJ is shown in <xref
linkend="txoj-lifecycle" />.
</para>
<figure id="txoj-lifecycle">
Modified: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Using_TxCore.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Using_TxCore.xml 2010-09-29 03:12:48 UTC (rev 35340)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/Using_TxCore.xml 2010-09-29 05:39:10 UTC (rev 35341)
@@ -6,60 +6,338 @@
<chapter>
<title>Using TxCore</title>
<para>
-
+ This section describes TxCore and <application>Transactional Objects for Java (TXOJ)</application> in more detail,
+ and shows how to use TxCore to construct transactional applications.
</para>
<section>
<title>State management</title>
- <para>
-
- </para>
-
<section>
<title>Object states</title>
<para>
-
+ TxCore needs to be able to remember the state of an object for several purposes, including recovery (the state
+ represents some past state of the object), and for persistence (the state represents the final state of an
+ object at application termination). Since all of these requirements require common functionality they are all
+ implemented using the same mechanism - the classes Input/OutputObjectState and Input/OutputBuffer.
</para>
+ <example>
+ <title><classname>OutputBuffer</classname> and <classname>InputBuffer</classname></title>
+ <programlisting language="Java" role="JAVA"><xi:include href="extras/OutputBuffer.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ <programlisting language="Java" role="JAVA"><xi:include href="extras/InputBuffer.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ <para>
+ The <classname>InputBuffer</classname> and <classname>OutputBuffer</classname> classes maintain an internal
+ array into which instances of the standard Java types can be contiguously packed or unpacked, using the
+ <methodname>pack</methodname> or <methodname>unpack</methodname> operations. This buffer is automatically
+ resized as required should it have insufficient space. The instances are all stored in the buffer in a
+ standard form called <systemitem>network byte order</systemitem> to make them machine independent.
+ </para>
+ </example>
+ <example>
+ <title><classname>OutputObjectState</classname> and <classname>InputObjectState</classname></title>
+ <programlisting language="Java" role="JAVA"><xi:include href="extras/OutputObjectState.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ <programlisting language="Java" role="JAVA"><xi:include href="extras/InputObjectState.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ <para>
+ The <classname>InputObjectState</classname> and <classname>OutputObjectState</classname> classes provides all
+ the functionality of <classname>InputBuffer</classname> and <classname>OutputBuffer</classname>, through
+ inheritance, and add two additional instance variables that signify the Uid and type of the object for which
+ the <classname>InputObjectStat</classname> or <classname>OutputObjectState</classname> instance is a
+ compressed image. These are used when accessing the object store during storage and retrieval of the object
+ state.
+ </para>
+ </example>
</section>
<section>
<title>The object store</title>
<para>
-
+ The object store provided with TxCore deliberately has a fairly restricted interface so that it can be
+ implemented in a variety of ways. For example, object stores are implemented in shared memory, on the Unix file
+ system (in several different forms), and as a remotely accessible store. More complete information about the
+ object stores available in TxCore can be found in the Appendix. <!-- xref -->
</para>
+ <note>
+ <para>
+ As with all TxCore classes, the default object stores are pure Java implementations. to access the shared
+ memory and other more complex object store implementations, you need to use native methods.
+ </para>
+ </note>
+ <para>
+ All of the object stores hold and retrieve instances of the class <classname>InputObjectState</classname> or
+ <classname>OutputObjectState</classname>. These instances are named by the Uid and Type of the object that they
+ represent. States are read using the <methodname>read_committed</methodname> operation and written by the system
+ using the <methodname>write_uncommitted</methodname> operation. Under normal operation new object states do not
+ overwrite old object states but are written to the store as shadow copies. These shadows replace the original
+ only when the <methodname>commit_state</methodname> operation is invoked. Normally all interaction with the
+ object store is performed by TxCore system components as appropriate thus the existence of any shadow versions
+ of objects in the store are hidden from the programmer.
+ </para>
+ <example>
+ <title>StateStatus</title>
+ <programlisting language="Java" role="JAVA"><xi:include href="extras/StateStatus.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ </example>
+ <example>
+ <title>ObjectStore</title>
+ <programlisting language="Java" role="JAVA"><xi:include href="extras/ObjectStore.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ </example>
+ <para>
+ When a transactional object is committing, it must make certain state changes persistent, so it can recover in
+ the event of a failure and either continue to commit, or rollback. When using <application>TXOJ</application>,
+ TxCore will take care of this automatically. To guarantee <systemitem>ACID</systemitem> properties, these state
+ changes must be flushed to the persistence store implementation before the transaction can proceed to
+ commit. Otherwise, the application may assume that the transaction has committed when in fact the state changes
+ may still reside within an operating system cache, and may be lost by a subsequent machine failure. By default,
+ TxCore ensures that such state changes are flushed. However, doing so can impose a significant performance
+ penalty on the application.
+ </para>
+ <para><!-- How / where do you do this? -->
+ To prevent transactional object state flushes, set the
+ <varname>ObjectStoreEnvironmentBean.objectStoreSync</varname> variable to <literal>OFF</literal>.
+ </para>
</section>
<section>
<title>Selecting an object store implementation</title>
<para>
-
+ TxCore comes with support for several different object store implementations. The Appendix<!-- xref -->
+ describes these implementations, how to select and configure a given implementation on a per-object basis using
+ the <varname>ObjectStoreEnvironmentBean.objectStoreType</varname> property variable, and indicates how
+ additional implementations can be provided.
</para>
<section>
<title>StateManager</title>
<para>
+ The TxCore class <classname>StateManager</classname> manages the state of an object and provides all of the
+ basic support mechanisms required by an object for state management
+ purposes. <classname>StateManager</classname> is responsible for creating and registering appropriate
+ resources concerned with the persistence and recovery of the transactional object. If a transaction is nested,
+ then <classname>StateManager</classname> will also propagate these resources between child transactions and
+ their parents at commit time.
+ </para>
+ <para> <!-- This is the exact same stuff that is in the Recovery & Persistence chapter of Overview.xml -->
+ Objects are assumed to be of three possible flavours.
+ </para>
+ <variablelist>
+ <title>Three Flavors of Objects</title>
+ <varlistentry>
+ <term>Recoverable</term>
+ <listitem>
+ <para>
+ <classname>StateManager</classname> attempts to generate and maintain appropriate recovery information for
+ the object. Such objects have lifetimes that do not exceed the application program that creates them.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Recoverable and Persistent</term>
+ <listitem>
+ <para>
+ The lifetime of the object is assumed to be greater than that of the creating or accessing application, so
+ that in addition to maintaining recovery information, <classname>StateManager</classname> attempts to
+ automatically load or unload any existing persistent state for the object by calling the
+ <methodname>activate</methodname> or <methodname>deactivate</methodname> operation at appropriate times.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Neither Recoverable nor Persistent</term>
+ <listitem>
+ <para>
+ No recovery information is ever kept, nor is object activation or deactivation ever automatically
+ attempted.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <para>
+ This object property is selected at object construction time and cannot be changed thereafter. Thus an object
+ cannot gain (or lose) recovery capabilities at some arbitrary point during its lifetime.
+ </para>
+ <example>
+ <title>Object Store Implementation Using <classname>StateManager</classname></title>
+ <programlisting language="Java" role="JAVA"><xi:include href="extras/object_store_implementation_using_StateManager.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ </example>
+
+ <para>
+ If an object is recoverable or persistent, <classname>StateManager</classname> will invoke the operations
+ <methodname>save_state</methodname> (while performing deactivation), <methodname>restore_state</methodname>
+ (while performing activation), and <methodname>type</methodname> at various points during the execution of the
+ application. These operations must be implemented by the programmer since <classname>StateManager</classname>
+ does not have access to a runtime description of the layout of an arbitrary Java object in memory and thus
+ cannot implement a default policy for converting the in memory version of the object to its passive
+ form. However, the capabilities provided by <classname>InputObjectState</classname> and
+ <classname>OutputObjectState</classname> make the writing of these routines fairly simple. For example, the
+ <methodname>save_state</methodname> implementation for a class <classname>Example</classname> that had member
+ variables called <varname>A</varname>, <varname>B</varname>, and <varname>C</varname> could simply be <xref
+ linkend="example_methods_for_StateManager" />.
</para>
+ <example id="example_methods_for_StateManager">
+ <title>Example Implementation of Methods for <classname>StateManager</classname></title>
+ <programlisting language="Java" role="JAVA"><xi:include href="extras/example_methods_for_StateManager.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ </example>
+ <para>
+ In order to support crash recovery for persistent objects, all <methodname>save_state</methodname> and
+ <methodname>restore_state</methodname> methods of user objects must call
+ <methodname>super.save_state</methodname> and <methodname>super.restore_state</methodname>.
+ </para>
+ <note>
+ <para>
+ The <methodname>type</methodname> method is used to determine the location in the object store where the
+ state of instances of that class will be saved and ultimately restored. This location can actually be any
+ valid string. However, you should avoid using the hash character (#) as this is reserved for special
+ directories that TxCore requires.
+ </para>
+ </note>
+ <para>
+ The <methodname>get_uid</methodname> operation of <classname>StateManager</classname> provides read-only
+ access to an object’s internal system name for whatever purpose the programmer requires, such as registration
+ of the name in a name server. The value of the internal system name can only be set when an object is
+ initially constructed, either by the provision of an explicit parameter or by generating a new identifier when
+ the object is created.
+ </para>
+ <para>
+ The <methodname>destroy</methodname> method can be used to remove the object’s state from the object
+ store. This is an atomic operation, and therefore will only remove the state if the top-level transaction
+ within which it is invoked eventually commits. The programmer must obtain exclusive access to the object prior
+ to invoking this operation.
+ </para>
+ <para>
+ Since object recovery and persistence essentially have complimentary requirements (the only difference being
+ where state information is stored and for what purpose), <classname>StateManager</classname> effectively
+ combines the management of these two properties into a single mechanism. It uses instances of the classes
+ <classname>InputObjectState</classname> and <classname>OutputObjectState</classname> both for recovery and
+ persistence purposes. An additional argument passed to the <methodname>save_state</methodname> and
+ <methodname>restore_state</methodname> operations allows the programmer to determine the purpose for which any
+ given invocation is being made. This allows different information to be saved for recovery and persistence
+ purposes.
+ </para>
</section>
<section>
<title>Object models</title>
<para>
-
+ TxCore supports two models for objects, which affect how an objects state and concurrency control are implemented.
</para>
+ <variablelist>
+ <title>TxCore Object Models</title>
+ <varlistentry>
+ <term>Single</term>
+ <listitem>
+ <para>
+ Only a single copy of the object exists within the application. This copy resides within a single JVM,
+ and all clients must address their invocations to this server. This model provides better performance,
+ but represents a single point of failure, and in a multi-threaded environment may not protect the
+ object from corruption if a single thread fails.
+ </para>
+ <figure>
+ <title>Single Object Model</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/single_object_model.png" format="PNG"/>
+ </imageobject>
+ </mediaobject>
+ </figure>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Multiple</term>
+ <listitem>
+ <para>
+ Logically, a single instance of the object exists, but copies of it are distributed across different
+ JVMs. The performance of this model is worse than the SINGLE model, but it provides better failure
+ isolation.
+ </para>
+ <figure>
+ <title>Multiple Object Model</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/multiple_object_model.png" format="PNG"/>
+ </imageobject>
+ </mediaobject>
+ </figure>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <para>
+ The default model is SINGLE. The programmer can override this on a per-object basis by using the appropriate
+ constructor.
+ </para>
</section>
<section>
<title>Summary</title>
<para>
-
+ In summary, the TxCore class <classname>StateManager</classname> manages the state of an object and provides
+ all of the basic support mechanisms required by an object for state management purposes. Some operations must
+ be defined by the class developer. These operations are: <methodname>save_state</methodname>,
+ <methodname>restore_state</methodname>, and <methodname>type</methodname>.
</para>
+ <variablelist>
+ <varlistentry>
+ <term><type>boolean</type> <methodname>save_state</methodname>(<type>OutputObjectState</type> <varname>state</varname>, <type>int</type><varname>ObjectType</varname>)</term>
+ <listitem>
+ <para>
+ Invoked whenever the state of an object might need to be saved for future use, priqmarily for recovery
+ or persistence purposes. The <parameter>ObjectType</parameter> parameter indicates the reason that
+ <methodname>save_state</methodname> was invoked by TxCore. This enables the programmer to save different
+ pieces of information into the <classname>OutputObjectState</classname> supplied as the first parameter
+ depending upon whether the state is needed for recovery or persistence purposes. For example, pointers
+ to other TxCore objects might be saved simply as pointers for recovery purposes but as <type>Uid</type>s
+ for persistence purposes. As shown earlier, the <classname>OutputObjectState</classname> class provides
+ convenient operations to allow the saving of instances of all of the basic types in Java. In order to
+ support crash recovery for persistent objects it is necessary for all
+ <methodname>save_state</methodname> methods to call <methodname>super.save_state</methodname>.
+ </para>
+ <para>
+ <methodname>save_state</methodname> assumes that an object is internally consistent and that all
+ variables saved have valid values. It is the programmer's responsibility to ensure that this is the
+ case.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><type>boolean</type> <methodname>restore_state</methodname> (<type>InputObjectState</type> <varname>state</varname>, <type>int</type> <varname>ObjectType</varname>)</term>
+ <listitem>
+ <para>
+ Invoked whenever the state of an object needs to be restored to the one supplied. Once again the second
+ parameter allows different interpretations of the supplied state. In order to support crash recovery for
+ persistent objects it is necessary for all <methodname>restore_state</methodname> methods to call
+ <methodname>super.restore_state</methodname>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><type>String</type> <methodname>type</methodname> ()</term>
+ <listitem>
+ <para>
+ The TxCore persistence mechanism requires a means of determining the type of an object as a string so
+ that it can save or restore the state of the object into or from the object store. By convention this
+ information indicates the position of the class in the hierarchy. For example,
+ <literal>/StateManager/LockManager/Object</literal>.
+ </para>
+ <para>
+ The <methodname>type</methodname> method is used to determine the location in the object store where the
+ state of instances of that class will be saved and ultimately restored. This can actually be any valid
+ string. However, you should avoid using the hash character (#) as this is reserved for special
+ directories that TxCore requires.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
</section>
<section>
<title>Example</title>
<para>
-
+ Consider the following basic <classname>Array</classname> class derived from the
+ <classname>StateManager</classname> class. In this example, to illustrate saving and restoring of an object’s
+ state, the <varname>highestIndex</varname> variable is used to keep track of the highest element of the array
+ that has a non-zero value.
</para>
+ <example>
+ <title><classname>Array</classname> Class</title>
+ <programlisting language="Java" role="JAVA"><xi:include href="extras/Array_class.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ </example>
</section>
</section>
@@ -68,42 +346,248 @@
<section>
<title>Lock management and concurrency control</title>
<para>
-
+ Concurrency control information within TxCore is maintained by locks. Locks which are required to be shared
+ between objects in different processes may be held within a lock store, similar to the object store facility
+ presented previously. The lock store provided with TxCore deliberately has a fairly restricted interface so that
+ it can be implemented in a variety of ways. For example, lock stores are implemented in shared memory, on the Unix
+ file system (in several different forms), and as a remotely accessible store. More information about the object
+ stores available in TxCore can be found in the Appendix.<!-- xref -->
</para>
+ <note>
+ <para>
+ As with all TxCore classes, the default lock stores are pure Java implementations. To access the shared memory
+ and other more complex lock store implementations it is necessary to use native methods.
+ </para>
+ </note>
+ <example>
+ <title><classname>LockStore</classname></title>
+ <programlisting language="Java" role="JAVA"><xi:include href="extras/LockStore.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ </example>
<section>
<title>Selecting a lock store implementation</title>
<para>
-
+ TxCore comes with support for several different object store implementations. If the object model being used is
+ SINGLE, then no lock store is required for maintaining locks, since the information about the object is not
+ exported from it. However, if the MULTIPLE model is used, then different run-time environments (processes, Java
+ virtual machines) may need to share concurrency control information. The implementation type of the lock store
+ to use can be specified for all objects within a given execution environment using the
+ <varname>TxojEnvironmentBean.lockStoreType</varname> property variable. Currently this can have one of the
+ following values:
</para>
+ <variablelist>
+ <varlistentry>
+ <term>BasicLockStore</term>
+ <listitem>
+ <para>
+ This is an in-memory implementation which does not, by default, allow sharing of stored information
+ between execution environments. The application programmer is responsible for sharing the store
+ information.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>BasicPersistentLockStore</term>
+ <listitem>
+ <para>
+ This is the default implementation, and stores locking information within the local file system. Therefore
+ execution environments that share the same file store can share concurrency control information. The root
+ of the file system into which locking information is written is the <filename>LockStore</filename>
+ directory within the TxCore installation directory. You can override this at runtime by setting the
+ <varname>TxojEnvironmentBean.lockStoreDir</varname> property variable accordingly, or placing the location
+ within the <varname>CLASSPATH</varname>.
+ </para>
+ <screen>java -D TxojEnvironmentBean.lockStoreDir=/var/tmp/LockStore myprogram</screen>
+ <screen>java –classpath $CLASSPATH;/var/tmp/LockStore myprogram</screen>
+ <para>
+ If neither of these approaches is taken, then the default location will be at the same level as the
+ <filename>etc</filename> directory of the installation.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
</section>
<section>
<title>LockManager</title>
<para>
-
+ The concurrency controller is implemented by the class <classname>LockManager</classname>, which provides
+ sensible default behaviour, while allowing the programmer to override it if deemed necessary by the particular
+ semantics of the class being programmed. The primary programmer interface to the concurrency controller is via
+ the <methodname>setlock</methodname> operation. By default, the TxCore runtime system enforces strict two-phase
+ locking following a multiple reader, single writer policy on a per object basis. Lock acquisition is under
+ programmer control, since just as <classname>StateManager</classname> cannot determine if an operation modifies
+ an object, <classname>LockManager</classname> cannot determine if an operation requires a read or write
+ lock. Lock release, however, is normally under control of the system and requires no further intervention by the
+ programmer. This ensures that the two-phase property can be correctly maintained.
</para>
+ <para>
+ The <classname>LockManager</classname> class is primarily responsible for managing requests to set a lock on an
+ object or to release a lock as appropriate. However, since it is derived from
+ <classname>StateManager</classname>, it can also control when some of the inherited facilities are invoked. For
+ example, if a request to set a write lock is granted, then <classname>LockManager</classname> invokes modified
+ directly assuming that the setting of a write lock implies that the invoking operation must be about to modify
+ the object. This may in turn cause recovery information to be saved if the object is recoverable. In a similar
+ fashion, successful lock acquisition causes activate to be invoked.
+ </para>
+ <para>
+ Therefore, <classname>LockManager</classname> is directly responsible for activating and deactivating persistent
+ objects, as well as registering <systemitem>Resources</systemitem> for managing concurrency control. By driving
+ the <classname>StateManager</classname> class, it is also responsible for registering
+ <systemitem>Resources</systemitem> for persistent or recoverable state manipulation and object recovery. The
+ application programmer simply sets appropriate locks, starts and ends transactions, and extends the
+ <methodname>save_state</methodname> and <methodname>restore_state</methodname> methods of
+ <classname>StateManager</classname>.
+ </para>
+ <example>
+ <title><classname>LockResult</classname></title>
+ <programlisting language="Java" role="JAVA"> <xi:include href="extras/LockResult.java"
+ xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ </example>
+ <para>
+ The <methodname>setlock</methodname> operation must be parameterised with the type of lock required (READ or
+ WRITE), and the number of retries to acquire the lock before giving up. If a lock conflict occurs, one of the
+ following scenarios will take place:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ If the retry value is equal to <varname>LockManager.waitTotalTimeout</varname>, then the thread which called
+ <methodname>setlock</methodname> will be blocked until the lock is released, or the total timeout specified
+ has elapsed, and in which <literal>REFUSED</literal> will be returned.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ If the lock cannot be obtained initially then <classname>LockManager</classname> will try for the specified
+ number of retries, waiting for the specified timeout value between each failed attempt. The default is 100
+ attempts, each attempt being separated by a 0.25 seconds delay. The time between retries is specified in
+ micro-seconds.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ If a lock conflict occurs the current implementation simply times out lock requests, thereby preventing
+ deadlocks, rather than providing a full deadlock detection scheme. If the requested lock is obtained, the
+ <methodname>setlock</methodname> operation will return the value GRANTED, otherwise the value
+ <literal>REFUSED</literal> is returned. It is the responsibility of the programmer to ensure that the
+ remainder of the code for an operation is only executed if a lock request is granted. Below are examples of
+ the use of the setlock operation.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <example>
+ <title><methodname>setlock</methodname> Method Usage</title>
+ <programlisting language="Java" role="JAVA"> <xi:include href="extras/setlock.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ </example>
+ <para>
+ The concurrency control mechanism is integrated into the atomic action mechanism, thus ensuring that as locks
+ are granted on an object appropriate information is registered with the currently running atomic action to
+ ensure that the locks are released at the correct time. This frees the programmer from the burden of explicitly
+ freeing any acquired locks if they were acquired within atomic actions. However, if locks are acquired on an
+ object outside of the scope of an atomic action, it is the programmer's responsibility to release the locks when
+ required, using the corresponding releaselock operation.
+ </para>
</section>
<section>
<title>Locking policy</title>
<para>
-
+ Unlike many other systems, locks in TxCore are not special system types. Instead they are simply instances of
+ other TxCore objects (the class <classname>Lock</classname> which is also derived from
+ <classname>StateManager</classname> so that locks may be made persistent if required and can also be named in a
+ simple fashion). Furthermore, <classname>LockManager</classname> deliberately has no knowledge of the semantics
+ of the actual policy by which lock requests are granted. Such information is maintained by the actual
+ <classname>Lock</classname> class instances which provide operations (the <methodname>conflictsWith</methodname>
+ operation) by which <classname>LockManager</classname> can determine if two locks conflict or not. This
+ separation is important in that it allows the programmer to derive new lock types from the basic
+ <classname>Lock</classname> class and by providing appropriate definitions of the conflict operations enhanced
+ levels of concurrency may be possible.
</para>
+ <example>
+ <title><classname>LockMode</classname> Class</title>
+ <programlisting language="Java" role="JAVA"><xi:include href="extras/LockMode.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ </example>
+ <para>
+ The <classname>Lock</classname> class provides a <methodname>modifiesObject</methodname> operation which
+ <classname>LockManager</classname> uses to determine if granting this locking request requires a call on
+ modified. This operation is provided so that locking modes other than simple read and write can be
+ supported. The supplied <classname>Lock</classname> class supports the traditional multiple reader/single writer
+ policy.
+ </para>
</section>
<section>
<title>Object constructor and destructor</title>
<para>
-
+ Recall that TxCore objects can be recoverable, recoverable and persistent, or neither. Additionally each object
+ possesses a unique internal name. These attributes can only be set when that object is constructed. Thus
+ <classname>LockManager</classname> provides two protected constructors for use by derived classes, each of which
+ fulfils a distinct purpose
</para>
+ <variablelist>
+ <title>Protected Constructors Provided by <classname>LockManager</classname></title>
+ <varlistentry>
+ <term><methodname>LockManager ()</methodname></term>
+ <listitem>
+ <para>
+ This constructor allows the creation of new objects, having no prior state.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><methodname>LockManager</methodname> (<type>int</type> <varname>ObjectType</varname>, <type>int</type>
+ <varname>objectModel)</varname></term>
+ <listitem>
+ <para>
+ As above, this constructor allows the creation of new objects having no prior state. exist. The
+ <varname>ObjectType</varname> parameter determines whether an object is simply recoverable (indicated by
+ <literal>RECOVERABLE</literal>), recoverable and persistent (indicated by
+ <literal>ANDPERSISTENT</literal>), or neither (indicated by <literal>NEITHER</literal>). If an object is
+ marked as being persistent then the state of the object will be stored in one of the object stores. The
+ shared parameter only has meaning if it is <literal>RECOVERABLE</literal>. If the object model is
+ <literal>SINGLE</literal> (the default behaviour) then the recoverable state of the object is maintained
+ within the object itself, and has no external representation). Otherwise an in-memory (volatile) object
+ store is used to store the state of the object between atomic actions.
+ </para>
+ <para>
+ Constructors for new persistent objects should make use of atomic actions within themselves. This will
+ ensure that the state of the object is automatically written to the object store either when the action in
+ the constructor commits or, if an enclosing action exists, when the appropriate top-level action
+ commits. Later examples in this chapter illustrate this point further.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><methodname>LockManager</methodname>(<type>Uid</type> <varname>objUid</varname>)</term>
+ <listitem>
+ <para>
+ This constructor allows access to an existing persistent object, whose internal name is given by the
+ <varname>objUid</varname> parameter. Objects constructed using this operation will normally have their
+ prior state (identified by <varname>objUid</varname>) loaded from an object store automatically by the
+ system.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><methodname>LockManager</methodname>(<type>Uid</type> <varname>objUid</varname>, <type>int</type>
+ <varname>objectModel</varname>)</term>
+ <listitem>
+ <para>
+ As above, this constructor allows access to an existing persistent object, whose internal name is given by
+ the <varname>objUid</varname> parameter. Objects constructed using this operation will normally have their
+ prior state (identified by <varname>objUid</varname>) loaded from an object store automatically by the
+ system. If the object model is <literal>SINGLE</literal> (the default behaviour), then the object will not
+ be reactivated at the start of each top-level transaction.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <para>
+ The destructor of a programmer-defined class must invoke the inherited operation
+ <methodname>terminate</methodname> to inform the state management mechanism that the object is about to be
+ destroyed. Otherwise, unpredictable results may occur.
+ </para>
</section>
-
-
</section>
-
-
-
-
</chapter>
-
Added: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/Array_class.java
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/Array_class.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/Array_class.java 2010-09-29 05:39:10 UTC (rev 35341)
@@ -0,0 +1,79 @@
+public class Array extends StateManager
+{
+ public Array ();
+ public Array (Uid objUid);
+ public void finalize ( super.terminate(); };
+
+ /* Class specific operations. */
+
+ public boolean set (int index, int value);
+ public int get (int index);
+
+ /* State management specific operations. */
+
+ public boolean save_state (OutputObjectState os, int ObjectType);
+ public boolean restore_state (InputObjectState os, int ObjectType);
+ public String type ();
+
+ public static final int ARRAY_SIZE = 10;
+
+ private int[] elements = new int[ARRAY_SIZE];
+ private int highestIndex;
+};
+The save_state, restore_state and type operations can be defined as follows:
+ /* Ignore ObjectType parameter for simplicity */
+
+ public boolean save_state (OutputObjectState os, int ObjectType)
+ {
+ if (!super.save_state(os, ObjectType))
+ return false;
+
+ try
+ {
+ packInt(highestIndex);
+
+ /*
+ * Traverse array state that we wish to save. Only save active elements
+ */
+
+ for (int i = 0; i <= highestIndex; i++)
+ os.packInt(elements[i]);
+
+ return true;
+ }
+ catch (IOException e)
+ {
+ return false;
+ }
+ }
+public boolean restore_state (InputObjectState os, int ObjectType)
+{
+ if (!super.restore_state(os, ObjectType))
+ return false;
+
+ try
+ {
+ int i = 0;
+
+ highestIndex = os.unpackInt();
+
+ while (i < ARRAY_SIZE)
+ {
+ if (i <= highestIndex)
+ elements[i] = os.unpackInt();
+ else
+ elements[i] = 0;
+ i++;
+ }
+
+ return true;
+ }
+ catch (IOException e)
+ {
+ return false;
+ }
+}
+public String type ()
+{
+ return "/StateManager/Array";
+}
Added: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/InputBuffer.java
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/InputBuffer.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/InputBuffer.java 2010-09-29 05:39:10 UTC (rev 35341)
@@ -0,0 +1,21 @@
+public class InputBuffer
+{
+ public InputBuffer ();
+
+ public final synchronized boolean valid ();
+ public synchronized byte[] buffer();
+ public synchronized int length ();
+
+ /* unpack operations for standard Java types */
+
+ public synchronized byte unpackByte () throws IOException;
+ public synchronized byte[] unpackBytes () throws IOException;
+ public synchronized boolean unpackBoolean () throws IOException;
+ public synchronized char unpackChar () throws IOException;
+ public synchronized short unpackShort () throws IOException;
+ public synchronized int unpackInt () throws IOException;
+ public synchronized long unpackLong () throws IOException;
+ public synchronized float unpackFloat () throws IOException;
+ public synchronized double unpackDouble () throws IOException;
+ public synchronized String unpackString () throws IOException;
+};
\ No newline at end of file
Added: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/InputObjectState.java
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/InputObjectState.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/InputObjectState.java 2010-09-29 05:39:10 UTC (rev 35341)
@@ -0,0 +1,9 @@
+class InputObjectState extends InputBuffer
+{
+ public OutputObjectState (Uid newUid, String typeName, byte[] b);
+
+ public boolean notempty ();
+ public int size ();
+ public Uid stateUid ();
+ public String type ();
+};
\ No newline at end of file
Added: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/LockMode.java
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/LockMode.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/LockMode.java 2010-09-29 05:39:10 UTC (rev 35341)
@@ -0,0 +1,25 @@
+public class LockMode
+{
+ public static final int READ;
+ public static final int WRITE;
+};
+
+public class LockStatus
+{
+ public static final int LOCKFREE;
+ public static final int LOCKHELD;
+ public static final int LOCKRETAINED;
+};
+
+public class Lock extends StateManager
+{
+ public Lock (int lockMode);
+
+ public boolean conflictsWith (Lock otherLock);
+ public boolean modifiesObject ();
+
+ public boolean restore_state (InputObjectState os, int ObjectType);
+ public boolean save_state (OutputObjectState os, int ObjectType);
+ public String type ();
+ . . .
+};
\ No newline at end of file
Added: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/LockResult.java
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/LockResult.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/LockResult.java 2010-09-29 05:39:10 UTC (rev 35341)
@@ -0,0 +1,37 @@
+public class LockResult
+{
+ public static final int GRANTED;
+ public static final int REFUSED;
+ public static final int RELEASED;
+};
+
+public class ConflictType
+{
+ public static final int CONFLICT;
+ public static final int COMPATIBLE;
+ public static final int PRESENT;
+};
+
+public abstract class LockManager extends StateManager
+{
+ public static final int defaultTimeout;
+ public static final int defaultRetry;
+ public static final int waitTotalTimeout;
+
+ public synchronized int setlock (Lock l);
+ public synchronized int setlock (Lock l, int retry);
+ public synchronized int setlock (Lock l, int retry, int sleepTime);
+ public synchronized boolean releaselock (Uid uid);
+
+ /* abstract methods inherited from StateManager */
+
+ public boolean restore_state (InputObjectState os, int ObjectType);
+ public boolean save_state (OutputObjectState os, int ObjectType);
+ public String type ();
+
+ protected LockManager ();
+ protected LockManager (int ObjectType, int objectModel);
+ protected LockManager (Uid storeUid);
+ protected LockManager (Uid storeUid, int ObjectType, int objectModel);
+ . . .
+};
\ No newline at end of file
Added: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/LockStore.java
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/LockStore.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/LockStore.java 2010-09-29 05:39:10 UTC (rev 35341)
@@ -0,0 +1,9 @@
+public class LockStore
+{
+ public abstract InputObjectState read_state (Uid u, String tName)
+ throws LockStoreException;
+
+ public abstract boolean remove_state (Uid u, String tname);
+ public abstract boolean write_committed (Uid u, String tName,
+ OutputObjectState state);
+};
\ No newline at end of file
Added: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/ObjectStore.java
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/ObjectStore.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/ObjectStore.java 2010-09-29 05:39:10 UTC (rev 35341)
@@ -0,0 +1,11 @@
+public abstract class ObjectStore
+{
+ /* The abstract interface */
+ public abstract boolean commit_state (Uid u, String name)
+ throws ObjectStoreException;
+ public abstract InputObjectState read_committed (Uid u, String name)
+ throws ObjectStoreException;
+ public abstract boolean write_uncommitted (Uid u, String name,
+ OutputObjectState os) throws ObjectStoreException;
+ . . .
+};
\ No newline at end of file
Added: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/OutputBuffer.java
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/OutputBuffer.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/OutputBuffer.java 2010-09-29 05:39:10 UTC (rev 35341)
@@ -0,0 +1,21 @@
+public class OutputBuffer
+{
+ public OutputBuffer ();
+
+ public final synchronized boolean valid ();
+ public synchronized byte[] buffer();
+ public synchronized int length ();
+
+ /* pack operations for standard Java types */
+
+ public synchronized void packByte (byte b) throws IOException;
+ public synchronized void packBytes (byte[] b) throws IOException;
+ public synchronized void packBoolean (boolean b) throws IOException;
+ public synchronized void packChar (char c) throws IOException;
+ public synchronized void packShort (short s) throws IOException;
+ public synchronized void packInt (int i) throws IOException;
+ public synchronized void packLong (long l) throws IOException;
+ public synchronized void packFloat (float f) throws IOException;
+ public synchronized void packDouble (double d) throws IOException;
+ public synchronized void packString (String s) throws IOException;
+};
\ No newline at end of file
Added: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/OutputObjectState.java
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/OutputObjectState.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/OutputObjectState.java 2010-09-29 05:39:10 UTC (rev 35341)
@@ -0,0 +1,9 @@
+class OutputObjectState extends OutputBuffer
+{
+ public OutputObjectState (Uid newUid, String typeName);
+
+ public boolean notempty ();
+ public int size ();
+ public Uid stateUid ();
+ public String type ();
+};
Added: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/StateStatus.java
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/StateStatus.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/StateStatus.java 2010-09-29 05:39:10 UTC (rev 35341)
@@ -0,0 +1,8 @@
+public StateStatus
+{
+ public static final int OS_COMMITTED;
+ public static final int OS_UNCOMMITTED;
+ public static final int OS_COMMITTED_HIDDEN;
+ public static final int OS_UNCOMMITTED_HIDDEN;
+ public static final int OS_UNKNOWN;
+}
Added: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/example_methods_for_StateManager.java
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/example_methods_for_StateManager.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/example_methods_for_StateManager.java 2010-09-29 05:39:10 UTC (rev 35341)
@@ -0,0 +1,18 @@
+public boolean save_state ( OutputObjectState os, int ObjectType )
+{
+ if (!super.save_state(os, ObjectType))
+ return false;
+
+ try
+ {
+ os.packInt(A);
+ os.packString(B);
+ os.packFloat(C);
+
+ return true;
+ }
+ catch (IOException e)
+ {
+ return false;
+ }
+}
\ No newline at end of file
Added: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/object_store_implementation_using_StateManager.java
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/object_store_implementation_using_StateManager.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/object_store_implementation_using_StateManager.java 2010-09-29 05:39:10 UTC (rev 35341)
@@ -0,0 +1,47 @@
+public class ObjectStatus
+{
+ public static final int PASSIVE;
+ public static final int PASSIVE_NEW;
+ public static final int ACTIVE;
+ public static final int ACTIVE_NEW;
+ public static final int UNKNOWN_STATUS;
+};
+
+public class ObjectType
+{
+ public static final int RECOVERABLE;
+ public static final int ANDPERSISTENT;
+ public static final int NEITHER;
+};
+
+public abstract class StateManager
+{
+ public synchronized boolean activate ();
+ public synchronized boolean activate (String storeRoot);
+ public synchronized boolean deactivate ();
+ public synchronized boolean deactivate (String storeRoot, boolean commit);
+
+ public synchronized void destroy ();
+
+ public final Uid get_uid ();
+
+ public boolean restore_state (InputObjectState, int ObjectType);
+ public boolean save_state (OutputObjectState, int ObjectType);
+ public String type ();
+ . . .
+
+ protected StateManager ();
+ protected StateManager (int ObjectType, int objectModel);
+ protected StateManager (Uid uid);
+ protected StateManager (Uid uid, int objectModel);
+ . . .
+
+ protected final void modified ();
+ . . .
+};
+
+public class ObjectModel
+{
+ public static final int SINGLE;
+ public static final int MULTIPLE;
+};
\ No newline at end of file
Added: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/setlock.java
===================================================================
--- labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/setlock.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/extras/setlock.java 2010-09-29 05:39:10 UTC (rev 35341)
@@ -0,0 +1,11 @@
+res = setlock(new Lock(WRITE), 10); // Will attempt to set a
+ // write lock 11 times (10
+ // retries) on the object
+ // before giving up.
+res = setlock(new Lock(READ), 0); // Will attempt to set a read
+ // lock 1 time (no retries) on
+ // the object before giving up.
+res = setlock(new Lock(WRITE); // Will attempt to set a write
+ // lock 101 times (default of
+ // 100 retries) on the object
+ // before giving up.
Added: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/images/multiple_object_model.png
===================================================================
(Binary files differ)
Property changes on: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/images/multiple_object_model.png
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Added: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/images/single_object_model.png
===================================================================
(Binary files differ)
Property changes on: labs/jbosstm/trunk/ArjunaCore/docs/user_guide/ArjunaCore_Development_Guide/en-US/images/single_object_model.png
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
More information about the jboss-svn-commits
mailing list