[jboss-cvs] JBossAS SVN: r78381 - 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
Wed Sep 10 23:53:36 EDT 2008
Author: xhuang at jboss.com
Date: 2008-09-10 23:53:36 -0400 (Wed, 10 Sep 2008)
New Revision: 78381
Modified:
projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/zh-CN/Replication.po
Log:
udpate
Modified: projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/zh-CN/Replication.po
===================================================================
--- projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/zh-CN/Replication.po 2008-09-11 03:20:19 UTC (rev 78380)
+++ projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/zh-CN/Replication.po 2008-09-11 03:53:36 UTC (rev 78381)
@@ -9,7 +9,7 @@
"Project-Id-Version: Replication\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2008-05-30 04:03+0000\n"
-"PO-Revision-Date: 2008-09-10 11:07+1000\n"
+"PO-Revision-Date: 2008-09-11 13:53+1000\n"
"Last-Translator: Xi HUANG <xhuang at redhat.com>\n"
"Language-Team: <en at li.org>\n"
"MIME-Version: 1.0\n"
@@ -78,7 +78,7 @@
"also offers a replication queue, where modifications are replicated "
"periodically (i.e. interval-based), or when the queue size exceeds a number "
"of elements, or a combination thereof."
-msgstr ""
+msgstr "复制可以同步也可以异步进行。使用哪种方式取决于应用程序。同步复制阻塞调用者（如 put() 直到所有修改都已成功复制到群集里的所有节点才完成）。异步复制则在后台执行复制（put() 马上会返回）。<literal>TreeCache</literal> 也提供一个复制队列，修改将被定期地复制（如根据设定的时间间隔），或者在超出队列大小一定限额时进行，亦或两者结合进行。"
#. Tag: para
#: Replication.xml:29
@@ -93,13 +93,13 @@
"asynchronous replication, errors are simply written to a log. Even when "
"using transactions, a transaction may succeed but replication may not "
"succeed on all <literal>TreeCache</literal> instances."
-msgstr ""
+msgstr "异步复制更快（不会阻塞调用者），因为同步复制要求从群集里所有节点获得应答来确定已经接收到并成功应用了相关修改（考虑到往返时间）。然而，当同步复制成功返回时，调用者确实知道所有修改都已经成功应用到了所有节点，而异步复制就未必了。进行异步复制时，发生的错误只是简单地写入到日志里。而使用事务时，可能事务成功完成了，但并非所有 <literal>TreeCache</literal> 实例上的复制都会成功。"
#. Tag: title
#: Replication.xml:33
#, no-c-format
msgid "Replicated Caches and Transactions"
-msgstr ""
+msgstr "复制性缓存和事务"
#. Tag: para
#: Replication.xml:34
@@ -111,7 +111,7 @@
"individual modifications, and can be a lot more efficient than not using "
"transactions. Another effect of this is that if a transaction were to roll "
"back, nothing is broadcast across a cluster."
-msgstr ""
+msgstr "在使用事务时，复制只发生在事务边界，也就是说，发生在事务提交的时候。这可以最小化进行复制所需的负载，因为这会广播单个的修改而不是一系列单独的修改，而且这比不使用事务效率高得多。其另外一个好处是，事务回滚不会在群集里广播消息。"
#. Tag: para
#: Replication.xml:37
@@ -122,12 +122,15 @@
"\"http://en.wikipedia.org/wiki/Two-phase_commit_protocol\">two phase commit</"
"ulink> protocol, respectively."
msgstr ""
+"根据你使用异步或同步模式运行群集，JBoss Cache 将分别使用单阶段或<ulink url="
+"\"http://en.wikipedia.org/wiki/Two-phase_commit_protocol\">两阶段提交</"
+"ulink>协议。"
#. Tag: title
#: Replication.xml:41
#, no-c-format
msgid "One Phase Commits"
-msgstr ""
+msgstr "单阶段提交"
#. Tag: para
#: Replication.xml:42
@@ -138,13 +141,13 @@
"local in-memory state and commit locally. Remote errors/rollbacks are never "
"fed back to the originator of the transaction since the communication is "
"asynchronous."
-msgstr ""
+msgstr "当缓存模式为 REPL_ASYNC 时使用它。所有的修改都在单一调用里被复制，指示远程缓存把修改应用到它们本地的内存状态并在本地进行提交。既然通信是异步的，远程的错误/回滚都不会反馈给事务的发起者。"
#. Tag: title
#: Replication.xml:48
#, no-c-format
msgid "Two Phase Commits"
-msgstr ""
+msgstr "两阶段提交"
#. Tag: para
#: Replication.xml:49
@@ -157,7 +160,7 @@
"to the prepare call, the originator of the transaction broadcasts a commit. "
"This instructs all remote caches to commit their data. If any of the caches "
"fail to respond to the prepare phase, the originator broadcasts a rollback."
-msgstr ""
+msgstr "当缓存模式为 REPL_SYNC 时使用它。在提交事务时，JBoss Cache 将广播一个 prepare 调用，它承载所有和事务相关的修改。然后远程缓存会获取其内存状态的本地锁并应用修改。一旦所有的远程缓存都响应了这个 prepare 调用，事务的发起者将广播一个提交消息。这指示所有的远程缓存提交它们的数据。如果任何一个缓存没有响应这个 prepare 调用，事务的发起者将广播一个回滚消息。"
#. Tag: para
#: Replication.xml:52
@@ -173,12 +176,15 @@
"can be forced to be synchronous using the <literal>SyncCommitPhase</literal> "
"and <literal>SyncRollbackPhase</literal> configuration options."
msgstr ""
+"请注意，虽然 prepare 阶段是同步的，提交和回滚阶段却是异步的。这是因为 <ulink url=\"http://java.sun.com/"
+"products/jta/\">Sun 的 JTA 规格</ulink>没有指定事务性资源在此时该如何处理故障；而参与事务的其他资源可能具有不确定的状态。因此，我们除去了事务在这个阶段的同步通信开销，也就是使用 <literal>SyncCommitPhase</literal> "
+"和 <literal>SyncRollbackPhase</literal> 配置选项迫使它们同步。"
#. Tag: title
#: Replication.xml:60
#, no-c-format
msgid "Buddy Replication"
-msgstr ""
+msgstr "Buddy 复制"
#. Tag: para
#: Replication.xml:61
@@ -189,7 +195,7 @@
"in the cluster, and only replicates to these specific buddies. This greatly "
"helps scalability as there is no longer a memory and network traffic impact "
"every time another instance is added to a cluster."
-msgstr ""
+msgstr "Buddy 复制允许你不把数据复制到群集里的所有节点。相反，每个实例在群集里选择一个或多个 'buddy' 且只复制到这些选定的 buddy 里。这极大地提高了可扩充性，因为新实例加入到群集里不会对内存和网络负载产生影响。"
#. Tag: para
#: Replication.xml:64
@@ -204,7 +210,7 @@
"that this is always accessed on one instance rather than in a round-robin "
"fashion as this helps the cache cluster optimise how it chooses buddies, "
"where it stores data, and minimises replication traffic."
-msgstr ""
+msgstr "Buddy 复制最常见的例子是 servlet 容器使用复制性缓存来存储 HTTP 会话数据。Buddy 复制运行正常并带来实质性好处的一个前提条件是对 <emphasis>session affinity</emphasis> 的使用，它也被称为 HTTP 会话复制方面的 <emphasis>sticky sessions</emphasis>。它表示如果某些数据被频繁使用，那么这些数据最好位于同一实例里，而不是以 round-robin 的方式进行访问。这可以帮助缓存群集优化 buddy 的选择、存数据的储位置并最小化复制负载。"
#. Tag: para
#: Replication.xml:67
@@ -212,13 +218,13 @@
msgid ""
"If this is not possible, Buddy Replication may prove to be more of an "
"overhead than a benefit."
-msgstr ""
+msgstr "如果这不能实现，那么 Buddy 复制将被证明是一个负担而并不能带来好处。"
#. Tag: title
#: Replication.xml:71
#, no-c-format
msgid "Selecting Buddies"
-msgstr ""
+msgstr "选择 Buddy"
#. Tag: para
#: Replication.xml:72
@@ -233,6 +239,9 @@
"selects the next member in the cluster, as the name suggests, and guarantees "
"an even spread of buddies for each instance."
msgstr ""
+"Buddy 复制选择使用一个 <literal>org.jboss.cache."
+"buddyreplication.BuddyLocator</literal> 实例，它包含在网络里选择 buddy 的逻辑。JBoss Cache 目前带有一个实现 <literal>org.jboss.cache.buddyreplication."
+"NextMemberBuddyLocator</literal>，如果没有其他实现，它将被缺省使用。顾名思义，<literal>NextMemberBuddyLocator</literal> 选择群集里的下一个成员，并保证为每个实例平均分配 buddy。"
#. Tag: para
#: Replication.xml:75
@@ -240,7 +249,7 @@
msgid ""
"The <literal>NextMemberBuddyLocator</literal> takes in 2 parameters, both "
"optional."
-msgstr ""
+msgstr "<literal>NextMemberBuddyLocator</literal> 使用两个可选参数。"
#. Tag: para
#: Replication.xml:78
@@ -248,7 +257,7 @@
msgid ""
"<literal>numBuddies</literal> - specifies how many buddies each instance "
"should pick to back its data onto. This defaults to 1."
-msgstr ""
+msgstr "<literal>numBuddies</literal> - 指定每个实例应该选择多少个 buddy 来存储数据。它的缺省值为 1。"
#. Tag: para
#: Replication.xml:81
@@ -258,17 +267,18 @@
"<emphasis>try</emphasis> to select a buddy on a different physical host. If "
"not able to do so though, it will fall back to colocated instances. This "
"defaults to <literal>true</literal>."
-msgstr ""
+msgstr "<literal>ignoreColocatedBuddies</literal> - 表示每个实例都将<emphasis>试图</emphasis>选择一个不同主机上的 buddy。如果不能这样做，它将成为 colocated 实例。它的缺省值为 <literal>true</literal>。 "
#. Tag: title
#: Replication.xml:88
#, no-c-format
msgid "BuddyPools"
-msgstr ""
+msgstr "Buddy 池"
#. Tag: para
#: Replication.xml:89
#, no-c-format
+#, fuzzy
msgid ""
"Also known as replication groups, a buddy pool is an optional construct "
"where each instance in a cluster may be configured with a buddy pool name. "
@@ -281,7 +291,7 @@
"picking an instance on a different host on the same rack, "
"<literal>BuddyLocator</literal>s would rather pick the instance in the same "
"buddy pool, on a separate rack which may add a degree of redundancy."
-msgstr ""
+msgstr "也称为复制组，buddy 池是一个可选的结构，群集里的每个实例都可能配置一个 buddy 池的名字。"
#. Tag: title
#: Replication.xml:95
More information about the jboss-cvs-commits
mailing list