[jboss-cvs] JBossAS SVN: r78225 - projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/zh-CN.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Tue Sep 9 02:18:45 EDT 2008
Author: xhuang at jboss.com
Date: 2008-09-09 02:18:44 -0400 (Tue, 09 Sep 2008)
New Revision: 78225
Modified:
projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/zh-CN/Transactions.po
Log:
update
Modified: projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/zh-CN/Transactions.po
===================================================================
--- projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/zh-CN/Transactions.po 2008-09-09 04:54:18 UTC (rev 78224)
+++ projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/zh-CN/Transactions.po 2008-09-09 06:18:44 UTC (rev 78225)
@@ -1,30 +1,32 @@
+# translation of Transactions.po to
# Language /tmp/mike/JBEAP420/Cache translations for JBEAP package.
-# Copyright (C) 2007 Free Software Foundation, Inc.
+# Copyright (C) 2007, 2008 Free Software Foundation, Inc.
# Automatically generated, 2007.
#
msgid ""
msgstr ""
-"Project-Id-Version: JBEAP 420\n"
+"Project-Id-Version: Transactions\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2008-05-30 04:03+0000\n"
-"PO-Revision-Date: 2001-02-09 01:25+0100\n"
-"Last-Translator: Automatically generated\n"
-"Language-Team: none\n"
+"PO-Revision-Date: 2008-09-10 02:18+1000\n"
+"Last-Translator: \n"
+"Language-Team: <en at li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
+"X-Generator: KBabel 1.11.4\n"
#. Tag: title
#: Transactions.xml:10
#, no-c-format
msgid "Transactions and Concurrency"
-msgstr ""
+msgstr "事务和并行性"
#. Tag: title
#: Transactions.xml:12
#, no-c-format
msgid "Concurrent Access"
-msgstr ""
+msgstr "并行访问"
#. Tag: para
#: Transactions.xml:13
@@ -33,13 +35,13 @@
"JBoss Cache uses a pessimistic locking scheme by default to prevent "
"concurrent access to the same data. Optimistic locking may alternatively be "
"used, and is discussed later."
-msgstr ""
+msgstr "JBoss Cache 缺省使用悲观锁模式来阻止对相同数据的并行访问。乐观锁也可以被使用，我们在后面将进行讨论。"
#. Tag: title
#: Transactions.xml:17
#, no-c-format
msgid "Locks"
-msgstr ""
+msgstr "锁"
#. Tag: para
#: Transactions.xml:18
@@ -51,6 +53,8 @@
"hold locks for \"a\", \"b\" and \"c\", we only need to acquire a lock for \"d"
"\"."
msgstr ""
+"锁基于节点级别在内部完成。例如，当我们想访问 \"/a/b/c\"，我们需要获取对节点 \"a\"、\"b\" 和 \"c\" 的锁。当在同一个事务里想访问 \"/a/b/c/d\"，因为我们已经持有对 \"a\"、\"b\" 和 \"c\" 的锁，那我们只需再获取对节点 \"d"
+"\" 的锁。"
#. Tag: para
#: Transactions.xml:21
@@ -64,7 +68,7 @@
"two-phase commit protocol (see below) across the cluster, the "
"<literal>GlobalTransaction</literal> uniquely identifies the unit of work "
"across a cluster."
-msgstr ""
+msgstr "锁拥有者可以是事务（调用发生在现存事务的内部）或线程（没有事务和调用相关联）。而事务或线程都在内部转换成 <literal>GlobalTransaction</literal> 实例，它被用作跨群集的唯一的全局 ID。例如，当我们运行跨群集的两阶段提交协议（下例），<literal>GlobalTransaction</literal> 将唯一地识别相关的工作单元。"
#. Tag: para
#: Transactions.xml:24
@@ -77,7 +81,7 @@
"has to wait until all read locks have been released. When scheduled "
"concurrently, write locks always have precedence over read locks. Note that "
"(if enabled) read locks can be upgraded to write locks."
-msgstr ""
+msgstr "锁可以是读锁或写锁。写锁序列化读和写，但只读锁只序列化读操作。当持有写锁时，其他写或读锁不能被获取。当持有读锁时，其他线程/事务则也可以获取读锁。然而，要获取写锁，线程/事务要等到所有读锁被释放为止。当进行并行调度时，写锁总是具有比读锁更高的优先级。请注意，读锁可以升级为写锁。"
#. Tag: para
#: Transactions.xml:27
@@ -92,12 +96,14 @@
"lock for \"/a/b/n2\". This allows for more concurrency in accessing the "
"cache."
msgstr ""
+"读 - 写锁可用于下列场景：假设有一个带有条目 \"/a/b/n1\" 和 \"/a/b/n2\" 的树。如果使用写锁，当 Tx1 访问 \"/"
+"a/b/n1\" 时，在 Tx1 已经完成并释放锁之前，Tx2 都不能访问 \"/a/b/n2\"。然而，如使用读锁，那这就有可能，因为 Tx1 要求 \"/a/b\" 的读锁和 \"/a/b/n1\" 的读写锁。然后 Tx2 能够获取 \"/a/b\" 的读锁以及 \"/a/b/n2\" 的读写锁。这使对缓存的访问具有更好的并行性。"
#. Tag: title
#: Transactions.xml:33
#, no-c-format
msgid "Pessimistic locking"
-msgstr ""
+msgstr "悲观锁"
#. Tag: para
#: Transactions.xml:34
@@ -106,13 +112,13 @@
"By default, JBoss Cache uses pessimistic locking. Locking is not exposed "
"directly to user. Instead, a transaction isolation level which provides "
"different locking behaviour is configurable."
-msgstr ""
+msgstr "在缺省情况下，JBoss Cache 使用悲观锁。锁不会直接对用户开放。相反，你可以配置提供不同的锁行为的事务隔离级别。"
#. Tag: title
#: Transactions.xml:38
#, no-c-format
msgid "Isolation levels"
-msgstr ""
+msgstr "隔离级别"
#. Tag: para
#: Transactions.xml:39
@@ -122,7 +128,7 @@
"to database ACID isolation levels. A user can configure an instance-wide "
"isolation level of NONE, READ_UNCOMMITTED, READ_COMMITTED, REPEATABLE_READ, "
"or SERIALIZABLE. REPEATABLE_READ is the default isolation level used."
-msgstr ""
+msgstr "JBoss Cache 支持下面的事务隔离级别，类似于数据库的 ACID 隔离级别。用户可以配置实例内的隔离级别为：NONE、READ_UNCOMMITTED、READ_COMMITTED、REPEATABLE_READ 或 SERIALIZABLE。缺省的隔离级别是 REPEATABLE_READ。"
#. Tag: para
#: Transactions.xml:44
@@ -131,7 +137,7 @@
"NONE. No transaction support is needed. There is no locking at this level, e."
"g., users will have to manage the data integrity. Implementations use no "
"locks."
-msgstr ""
+msgstr "NONE。不需要支持事务。这个基本没有锁，用户需要自己管理数据集成性。相关的实现没有使用锁。"
#. Tag: para
#: Transactions.xml:49
@@ -148,6 +154,11 @@
"Implementations typically use an exclusive lock for writes while reads don't "
"need to acquire a lock."
msgstr ""
+"READ_UNCOMMITTED。任何时候都可以读取数据，而写操作是互斥的。请注意，这个隔离级别不会阻止所谓的“脏读”（Tx1 里修改的数据可以在 Tx1 提交前被 Tx2 读取）。换句话说，如果你有下列的操作序列：<programlisting>\n"
+" Tx1 Tx2\n"
+" W\n"
+" R\n"
+"</programlisting>，使用这个隔离级别将不会执行 Tx2 读操作。相关实现通常在执行写操作时使用互斥锁，而进行读操作时则不需要获得锁。"
#. Tag: para
#: Transactions.xml:55
@@ -157,7 +168,7 @@
"level prevents the dirty read. But it doesn’t prevent the so-called "
"‘non-repeatable read’ where one thread reads the data twice can "
"produce different results. For example, if you have the following sequence,"
-msgstr ""
+msgstr "READ_COMMITTED。只要没有写操作，数据就可以被读取。这个级别阻止了“脏读”。当它不会阻止所谓的“不可重复读”（此时同一线程两次读取数据会产生不同的结果）。例如，如果你有下列的操作序列："
#. Tag: programlisting
#: Transactions.xml:56
@@ -168,12 +179,16 @@
" W\n"
" R"
msgstr ""
+"Tx1 Tx2\n"
+" R\n"
+" W\n"
+" R"
#. Tag: para
#: Transactions.xml:58
#, no-c-format
msgid "where the second read in Tx1 thread will produce different result."
-msgstr ""
+msgstr "Tx1 线程的第二次读操作将产生不同的结果。"
#. Tag: para
#: Transactions.xml:61
@@ -187,7 +202,7 @@
"a read-lock; this leads to nonrepeatable reads, where 2 reads of the same "
"data might return different values. Note that, the write only applies "
"regardless of transaction state (whether it has been committed or not)."
-msgstr ""
+msgstr "实现通常使用读-写锁；读操作在只有读操作时获取锁，而写操作必须等到没有更多人持有锁时才能获取锁。读操作通常在完成后才释放读锁，所以随后对同一数据的读操作必须重新获取读锁；这导致不可重复的读操作，两次读操作可能返回不同的结果。请注意，写操作的应用可以不管事务的状态（不管其是否已经提交与否）。"
#. Tag: para
#: Transactions.xml:66
@@ -198,7 +213,7 @@
"called \"phantom read\" where new data can be inserted into the tree from "
"the other transaction. Implementations typically use a read-write lock. This "
"is the default isolation level used."
-msgstr ""
+msgstr "REPEATABLE_READ。可以在没有写操作时读取数据，反之亦然。这个级别阻止了 \"non-repeatable read\" 但没有防止所谓的 \"phantom read\"，此时新的数据可以从其他事务中插入到树里。相关实现通常使用读-写锁。这是缺省的隔离级别。"
#. Tag: para
#: Transactions.xml:71
@@ -208,13 +223,13 @@
"writer or reader can have the lock at any given time. Locks are released at "
"the end of the transaction. Regarded as very poor for performance and thread/"
"transaction concurrency."
-msgstr ""
+msgstr "SERIALIZABLE。对数据的访问用互斥锁进行同步。在某一时刻只能有一个读取者或写入者可以持有锁。锁在事务结束时被释放。这对性能和线程/事务并行性影响很大。"
#. Tag: title
#: Transactions.xml:79
#, no-c-format
msgid "Insertion and Removal of Nodes"
-msgstr ""
+msgstr "插入和删除节点"
#. Tag: para
#: Transactions.xml:80
@@ -231,13 +246,13 @@
"<literal>false</literal>, insertions and removals of child nodes only "
"require the acquisition of a <emphasis>read lock</emphasis> on the parent "
"node."
-msgstr ""
+msgstr "在缺省情况下，在树里插入新节点或删除现有节点之前，JBoss Cache 都将试图获取新节点的父节点的写锁。这个方法把子节点当作父节点状态的一部分。它提供更好的准确性，但在频繁插入或删除节点时会付出更少并发性的代价。如果不在乎更好的准确性，JBoss Cache 提供一个配置选项 <literal>LockParentForChildInsertRemove</literal>。如果把它设置为 <literal>false</literal>，对子节点的插入或删除只会获取父节点的<emphasis>读锁</emphasis>。"
#. Tag: title
#: Transactions.xml:88
#, no-c-format
msgid "Optimistic locking"
-msgstr ""
+msgstr "乐观锁"
#. Tag: para
#: Transactions.xml:89
@@ -250,13 +265,13 @@
"locking allows for greater concurrency of threads and transactions by using "
"a technique called data versioning, explained here. Note that isolation "
"levels (if configured) are ignored if optimistic locking is enabled."
-msgstr ""
+msgstr "使用乐观锁的目的是为了提高并发性。当大量的线程对数据树的访问出现争议时，锁住树的一部分可能是低效的 - 对于读或写 - 如我们在悲观锁里做的一样对于整个事务期间。乐观锁通过使用名为数据版本（data versioning）的技术来增强线程和事务的并发性。请注意，如果启用了乐观锁，隔离级别（如果进行了配置）将被忽略。"
#. Tag: title
#: Transactions.xml:93
#, no-c-format
msgid "Architecture"
-msgstr ""
+msgstr "架构"
#. Tag: para
#: Transactions.xml:94
@@ -270,6 +285,8 @@
"invocation completes. Each transaction maintains a transaction workspace, "
"which contains a copy of the data used within the transaction."
msgstr ""
+"乐观锁把所有方法调用都视作事务性的<footnote><para> "
+"因为这个要求，使用乐观锁时你必须有一个事务管理者。</para> </footnote>。即使在事务的作用域里你不进行调用，JBoss Cache 也会创建一个隐含的事务并在调用完毕时提交这个事务。每个事务都维护一个事务工作空间，它包含事务里使用的数据的拷贝。"
#. Tag: para
#: Transactions.xml:100
@@ -285,7 +302,7 @@
"change it and commit before the first transaction can finish - the "
"transaction throws a <literal>RollbackException</literal> when committing "
"and the commit fails."
-msgstr ""
+msgstr "例如，如果事务调用 get(\"/a/b/c\")，节点 a、b 和 c 都从主数据树复制到工作空间里。数据都标记版本，事务里所有的调用都使用数据的拷贝而不是实际的数据。当事务提交时，它的工作空间将通过版本匹配合并回底层的树。如果存在不匹配的版本 - 例如实际的数据树有比工作空间更高的版本时（如果另外一个事务准备访问相同的数据，在第一个事务完成前修改数据并提交）- 事务在提交时将抛出 <literal>RollbackException</literal> 且提交会失败。"
#. Tag: para
#: Transactions.xml:103
@@ -295,7 +312,7 @@
"only held for a very short duration - at the start of a transaction to build "
"a workspace, and when the transaction commits and has to merge data back "
"into the tree."
-msgstr ""
+msgstr "乐观锁使用与我们上面所提及的相同的锁，但这些锁只保持很短的时间 - 在事务的开始构建一个工作空间，当事务提交时必须合并回数据树里。"
#. Tag: para
#: Transactions.xml:106
@@ -306,13 +323,13 @@
"inevitable overhead and extra processing of maintaining workspaces, "
"versioned data and validating on commit, it does buy you a near-SERIALIZABLE "
"degree of data integrity while maintaining a very high level of concurrency."
-msgstr ""
+msgstr "所以，虽然在版本检验失败时，乐观锁可能偶尔会失败，它也可能由于难以避免的开销和维护工作空间所耗费的额外处理、在提交时为数据标记版本，从而比悲观锁运行要慢，但它也使你可达到近乎 SERIALIZABLE 程度的数据集成性，并且保持非常高的并发性。"
#. Tag: title
#: Transactions.xml:112
#, no-c-format
msgid "Configuration"
-msgstr ""
+msgstr "配置"
#. Tag: para
#: Transactions.xml:113
@@ -320,7 +337,7 @@
msgid ""
"Optimistic locking is enabled by using the NodeLockingScheme XML attribute, "
"and setting it to \"OPTIMISTIC\":"
-msgstr ""
+msgstr "把 NodeLockingScheme XML 属性设置为 \"OPTIMISTIC\" 可以启用乐观锁："
#. Tag: programlisting
#: Transactions.xml:113
@@ -335,12 +352,20 @@
"<attribute name=\"NodeLockingScheme\">OPTIMISTIC</attribute>\n"
"..."
msgstr ""
+"...\n"
+"<!--\n"
+"Node locking scheme:\n"
+" OPTIMISTIC\n"
+" PESSIMISTIC (default)\n"
+"-->\n"
+"<attribute name=\"NodeLockingScheme\">OPTIMISTIC</attribute>\n"
+"..."
#. Tag: title
#: Transactions.xml:121
#, no-c-format
msgid "Transactional Support"
-msgstr ""
+msgstr "事务性支持"
#. Tag: para
#: Transactions.xml:122
@@ -352,19 +377,19 @@
"modifications are potentially<footnote><para> Depending on whether interval-"
"based asynchronous replication is used </para> </footnote> replicated after "
"every change (if replication is enabled)."
-msgstr ""
+msgstr "对 JBoss Cache 进行配置，你就可以使用事务来捆绑一系列工作，使其可以像一个单元一样复制。或者，如果禁用了事务支持，这和设置 AutoCommit 为 on 是相等的，这样修改将在每次变动后进行复制（如果启用了复制）<footnote><para> 取决于是否使用了使用时间间隔的异步复制</para> </footnote>。"
#. Tag: para
#: Transactions.xml:128
#, no-c-format
msgid "What JBoss Cache does on every incoming call (e.g. put()) is:"
-msgstr ""
+msgstr "JBoss Cache 对每次转入调用（如 put()）所做的是："
#. Tag: para
#: Transactions.xml:133
#, no-c-format
msgid "get the transaction associated with the thread"
-msgstr ""
+msgstr "获取和线程相关联的事务"
#. Tag: para
#: Transactions.xml:138
@@ -372,7 +397,7 @@
msgid ""
"register (if not already done) with the transaction manager to be notified "
"when a transaction commits or is rolled back."
-msgstr ""
+msgstr "向事务管理者注册（如果未注册），使其在事务提交或回滚时收到通知。"
#. Tag: para
#: Transactions.xml:143
@@ -382,6 +407,8 @@
"<literal>TransactionManagerLookup</literal> which returns a <literal>javax."
"transaction.TransactionManager</literal>."
msgstr ""
+"为了实现这一点，缓存必须配置返回 <literal>javax."
+"transaction.TransactionManager</literal> 的 <literal>TransactionManagerLookup</literal> 实例。"
#. Tag: para
#: Transactions.xml:146
@@ -399,6 +426,9 @@
"outside a Java EE Application Server. Being a dummy, however, this is just "
"for demo and testing purposes and is not recommended for production use."
msgstr ""
+"JBoss Cache 带有 <literal>JBossTransactionManagerLookup</literal> 和 "
+"<literal>GenericTransactionManagerLookup</literal>。<literal>JBossTransactionManagerLookup</literal> 能够绑定到运行的 JBoss 应用服务器并获取 <literal>TransactionManager</"
+"literal>，而<literal>GenericTransactionManagerLookup</literal> 可以绑定大多数流行的 Java EE 应用服务器且提供相同的功能。JBoss Cache 也提供一个傀儡实现 <literal>DummyTransactionManagerLookup</literal>，它可以用于独立的 JBoss Cache 应用程序，也可以用于在 Java EE 应用服务器之外运行的单元测试。作为傀儡实现，它只是用于演示和测试目的，我们不推荐将其用于产品环境。"
#. Tag: para
#: Transactions.xml:149
@@ -406,7 +436,7 @@
msgid ""
"The implementation of the <literal>JBossTransactionManagerLookup</literal> "
"is as follows:"
-msgstr ""
+msgstr "<literal>JBossTransactionManagerLookup</literal> 的实现是："
#. Tag: programlisting
#: Transactions.xml:152
@@ -424,6 +454,17 @@
" }\n"
"}"
msgstr ""
+"public class JBossTransactionManagerLookup implements "
+"TransactionManagerLookup {\n"
+"\n"
+" public JBossTransactionManagerLookup() {}\n"
+"\n"
+" public TransactionManager getTransactionManager() throws Exception {\n"
+" Object tmp=new InitialContext().lookup(\"java:/TransactionManager"
+"\");\n"
+" return (TransactionManager)tmp;\n"
+" }\n"
+"}"
#. Tag: para
#: Transactions.xml:153
@@ -431,7 +472,7 @@
msgid ""
"The implementation looks up the JBoss Transaction Manager from JNDI and "
"returns it."
-msgstr ""
+msgstr "这个实现从 JNDI 里查找 JBoss Transaction Manager 并返回它。"
#. Tag: para
#: Transactions.xml:156
@@ -445,7 +486,7 @@
"the <literal>TreeCache</literal> registers with the transaction to be "
"notified of transaction committed or aborted when it first encounters the "
"transaction."
-msgstr ""
+msgstr "当有调用进来时，<literal>TreeCache</literal> 获取当前的事务并把事务里的修改记录为键（如果没有事务，修改将马上应用并可能被复制）。所以，在事务的生存周期里，所有的修改都会被记录并和事务现关联。而且，<literal>TreeCache</literal> 在第一次遇到这个事务事将注册这个事务，使其在提交或终止时接到通知。"
#. Tag: para
#: Transactions.xml:159
@@ -453,7 +494,7 @@
msgid ""
"When a transaction rolls back, we undo the changes in the cache and release "
"all locks."
-msgstr ""
+msgstr "当事务回滚时，我们将取消缓存里的修改并释放所有的锁。"
#. Tag: para
#: Transactions.xml:162
@@ -467,6 +508,8 @@
"then sends back a success message. If a node in a cluster cannot acquire all "
"locks, or fails otherwise, it sends back a failure message."
msgstr ""
+"当事务提交时，我们初始化一个两阶段的提交协议<footnote><para> 只适用于同步复制或失效。"
+"</para> </footnote>：在第一阶段，包含当前事务的所有修改的 PREPARE 被发送到群集里的所有节点。每个节点都获取必需的锁并应用修改，然后回送一个成功消息。如果群集里的节点不能获取所有的锁，或者发生故障，它将回送一个失败消息。"
#. Tag: para
#: Transactions.xml:168
@@ -478,7 +521,7 @@
"initiated: a ROLLBACK message is sent to all nodes in the cluster. On "
"reception of the ROLLBACK message, every node undoes the changes for the "
"given transaction, and releases all locks held for the transaction."
-msgstr ""
+msgstr "两阶段提交协议的协调者等待所有的响应（或超时，以先发生的为准）。如果群集里的其中一个节点的响应为 FAIL（或者超时），回滚阶段将被初始化：ROLLBACK 消息将被发送到群集里的所有节点。接到 ROLLBACK 消息后，每个节点都会取消给定事务的修改，并释放为该事务保持的所有锁。"
#. Tag: para
#: Transactions.xml:171
@@ -487,7 +530,7 @@
"If all responses are OK, a COMMIT message is sent to all nodes in the "
"cluster. On reception of a COMMIT message, each node applies the changes for "
"the given transaction and releases all locks associated with the transaction."
-msgstr ""
+msgstr "如果所有响应都为 OK，那么 COMMIT 消息将被发送到群集里的所有节点。接到 COMMIT 消息后，每个节点都会在给定事务里应用修改并释放和该事务相关联的所有锁。"
#. Tag: para
#: Transactions.xml:174
@@ -496,13 +539,13 @@
"When we referred to 'transaction', we actually mean a global representation "
"of a local transaction, which uniquely identifies a transaction across a "
"cluster."
-msgstr ""
+msgstr "当提到“事务”时，我们实际上指的是本地事务的一个全局表示形式，它会唯一地识别群集里的事务。"
#. Tag: title
#: Transactions.xml:178
#, no-c-format
msgid "Example"
-msgstr ""
+msgstr "示例"
#. Tag: para
#: Transactions.xml:179
@@ -510,7 +553,7 @@
msgid ""
"Let's look at an example of how to use JBoss Cache in a standalone (i.e. "
"outside an application server) fashion with dummy transactions:"
-msgstr ""
+msgstr "让我们来看一个例子，学习怎样以独立运行的形式（如：在应用服务器之外）使用带有傀儡事务的 JBoss Cache："
#. Tag: programlisting
#: Transactions.xml:182
@@ -537,6 +580,26 @@
" try { tx.rollback(); } catch(Throwable t) {}\n"
"}"
msgstr ""
+"Properties prop = new Properties();\n"
+"prop.put(Context.INITIAL_CONTEXT_FACTORY, \"org.jboss.cache.transaction."
+"DummyContextFactory\");\n"
+"User Transaction tx=(UserTransaction)new InitialContext(prop).lookup"
+"(\"UserTransaction\");\n"
+"TreeCache tree = new TreeCache();\n"
+"PropertyConfigurator config = new PropertyConfigurator();\n"
+"config.configure(tree, \"META-INF/replSync-service.xml\");\n"
+"tree.createService(); // not necessary\n"
+"tree.startService(); // kick start tree cache\n"
+"\n"
+"try {\n"
+" tx.begin();\n"
+" tree.put(\"/classes/cs-101\", \"description\", \"the basics\");\n"
+" tree.put(\"/classes/cs-101\", \"teacher\", \"Ben\");\n"
+" tx.commit();\n"
+"}\n"
+"catch(Throwable ex) {\n"
+" try { tx.rollback(); } catch(Throwable t) {}\n"
+"}"
#. Tag: para
#: Transactions.xml:183
@@ -544,7 +607,7 @@
msgid ""
"The first lines obtain a user transaction using the 'JEE way' via JNDI. Note "
"that we could also say"
-msgstr ""
+msgstr "第一行包含一个通过 JNDI 使用 JEE 方式的用户事务。请注意，我们也可以说："
#. Tag: programlisting
#: Transactions.xml:187
@@ -553,6 +616,8 @@
"UserTransaction tx = new DummyUserTransaction(DummyTransactionManager."
"getInstance());"
msgstr ""
+"UserTransaction tx = new DummyUserTransaction(DummyTransactionManager."
+"getInstance());"
#. Tag: para
#: Transactions.xml:189
@@ -561,7 +626,7 @@
"Then we create a new TreeCache and configure it using a PropertyConfigurator "
"class and a configuration XML file (see below for a list of all "
"configuration options)."
-msgstr ""
+msgstr "然后，我们创建了一个新的 TreeCache 并用 PropertyConfigurator 类和配置 XML 文件（下面是所有配置选项的列表）对它进行配置。"
#. Tag: para
#: Transactions.xml:192
@@ -576,4 +641,5 @@
"exception in the methods (e.g. lock acquisition failed), or in the two-phase "
"commit protocol applying the modifications to all nodes in the cluster, the "
"transaction is rolled back."
-msgstr ""
+msgstr "然后启动缓存。我们接着启动一个事务（在内部将其与当前的线程关联）。对这个缓存调用的任何方法都将被收集，且只有当事务提交时才进行应用。在上面的例子里，我们创建了一个 \"/classes/cs-101\" 节点并添加了两个元素到它的表里。假设我们配置这个缓存使用同步复制，在事务提交时这些修改将被复制。如果在方法调用（如：获取锁失败）或在两阶段提交协议在群集的所有节点上应用修改时出现异常，事务将被回滚。"
+
More information about the jboss-cvs-commits
mailing list