[jbosscache-commits] JBoss Cache SVN: r7103 - core/trunk/src/main/docbook/faq/en.

[jbosscache-commits at lists.jboss.org]

Author: manik.surtani at jboss.com
Date: 2008-11-10 06:45:23 -0500 (Mon, 10 Nov 2008)
New Revision: 7103

Modified:
   core/trunk/src/main/docbook/faq/en/master.xml
Log:
Added FAQ on SELECT FOR UPDATE

Modified: core/trunk/src/main/docbook/faq/en/master.xml
===================================================================
--- core/trunk/src/main/docbook/faq/en/master.xml	2008-11-10 11:39:16 UTC (rev 7102)
+++ core/trunk/src/main/docbook/faq/en/master.xml	2008-11-10 11:45:23 UTC (rev 7103)
@@ -776,6 +776,36 @@
             </answer>
          </qandaentry>
 
+          <qandaentry>
+            <question>
+               <para>
+                   Does JBoss Cache support <literal>SELECT FOR UPDATE</literal> semantics?
+               </para>
+            </question>
+
+            <answer>
+               <para>
+                   Yes, but this is is only possible if you are running within a JTA transaction <emphasis>and</emphasis>
+                   are using either <literal>MVCC</literal> or <literal>PESSIMISTIC</literal> as your node locking scheme.
+               </para>
+               <para>
+                   To achieve <literal>SELECT FOR UPDATE</literal> semantics, simply do:
+               </para>
+               <programlisting role="JAVA"><![CDATA[
+
+    // start transaction ... 
+
+    cache.getInvocationContext().getOptionOverrides().setForceWriteLock(true);
+    Node n = cache.get("/a/b/c"); // this acquires a WRITE LOCK on this node
+        ...
+        ...
+
+    // end transaction
+
+                    ]]></programlisting>
+            </answer>
+         </qandaentry>
+
          <qandaentry>
             <question>
                <para>With replication (REPL_SYNC/REPL_ASYNC) or invalidation (INVALIDATION_SYNC/INVALIDATION_ASYNC), how