[jboss-cvs] JBossAS SVN: r78688 - 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
Thu Sep 18 20:34:37 EDT 2008
Author: xhuang at jboss.com
Date: 2008-09-18 20:34:37 -0400 (Thu, 18 Sep 2008)
New Revision: 78688
Modified:
projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/zh-CN/Replication.po
Log:
update
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-19 00:28:34 UTC (rev 78687)
+++ projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/zh-CN/Replication.po 2008-09-19 00:34:37 UTC (rev 78688)
@@ -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-15 05:58+1000\n"
+"PO-Revision-Date: 2008-09-19 20:34+1000\n"
"Last-Translator: \n"
"Language-Team: <en at li.org>\n"
"MIME-Version: 1.0\n"
@@ -278,7 +278,6 @@
#. 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. "
@@ -291,7 +290,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 "也称为复制组，buddy 池是一个可选的结构，群集里的每个实例都可能配置一个 buddy 池的名字。"
+msgstr "也称为复制组，buddy 池是一个可选的结构，群集里的每个实例都可能配置一个 buddy 池的名字。在选择 buddy 的时候，你可以把它想象成为一个“排他的俱乐部成样资格”，<literal>BuddyLocator</literal> 将尝试并选择共享相同的 Buddy 池名称的 buddy。这给予了系统管理员控制 buddy 选择某种程度的灵活性。例如，系统管理员可以把两个实例放在位于独立机架上的两个独立物理服务器上，而它们却在相同的 buddy 池里。所以，<literal>BuddyLocator</literal> 不是选择相同机架上不同主机里的实例，而是选择不同机架上相同的 buddy 池里的实例，这添加了某种程度的冗余性。"
#. Tag: title
#: Replication.xml:95
@@ -353,6 +352,8 @@
"in cache loaders will remain. This is useful if you have a shared cache "
"loader configured. Defaults to <literal>true</literal>."
msgstr ""
+"<literal>dataGravitationRemoveOnFind</literal> - 迫使拥有数据或备份的所有远程缓存删除该数据，因此使发出请求的缓存成为新的数据所有者。如果设置为 <literal>false</"
+"literal>，逐出而不是删除消息将被广播，所以持久化在缓存加载器里的任何状态将继续保留。如果你配置了共享缓存加载器，这会很有用。它缺省为 <literal>true</literal>。"
#. Tag: para
#: Replication.xml:111
@@ -363,7 +364,7 @@
"<literal>true</literal>. The resulting effect is that if this is "
"<literal>true</literal> then backup nodes can respond to data gravitation "
"requests in addition to data owners."
-msgstr ""
+msgstr "<literal>dataGravitationSearchBackupTrees</literal> - 请求远程实例搜索其备份以及主数据树。它的缺省值为 <literal>true</literal>。它如果为 <literal>true</literal>，除了数据所有者节点外，备份节点也将响应 data gravitation 请求。"
#. Tag: para
#: Replication.xml:114
@@ -377,12 +378,14 @@
"literal> is <literal>true</literal> this <literal>Option</literal> is "
"unnecessary."
msgstr ""
+"<literal>autoDataGravitation</literal> - 每次缓存丢失时，data gravitation 是否发生。设置为 <literal>false</literal> 可以阻止不必要的网络调用。多数情况下都知道何时进行 data gravitation 并传入一个 <literal>Option</literal> 来为每次调用启用 data gravitation。如果 <literal>autoDataGravitation</"
+"literal> 为 <literal>true</literal>，这个 <literal>Option</literal> 就没有必要了。"
#. Tag: title
#: Replication.xml:121
#, no-c-format
msgid "Implementation"
-msgstr ""
+msgstr "实现"
#. Tag: title
#: Replication.xml:124
@@ -390,13 +393,13 @@
msgid ""
"Class diagram of the classes involved in buddy replication and how they are "
"related to each other"
-msgstr ""
+msgstr "Buddy 复制里涉及的类的类图及其关系"
#. Tag: title
#: Replication.xml:135
#, no-c-format
msgid "Configuration"
-msgstr ""
+msgstr "配置"
#. Tag: programlisting
#: Replication.xml:137
@@ -462,12 +465,71 @@
"</config>\n"
"</attribute>"
msgstr ""
+"<!-- Buddy Replication config -->\n"
+"<attribute name=\"BuddyReplicationConfig\">\n"
+"<config>\n"
+" \n"
+"<!-- Enables buddy replication. This is the ONLY mandatory configuration "
+"element here. -->\n"
+"<buddyReplicationEnabled>true</buddyReplicationEnabled>\n"
+" \n"
+"<!-- These are the default values anyway -->\n"
+"<buddyLocatorClass>\n"
+" org.jboss.cache.buddyreplication.NextMemberBuddyLocator\n"
+"</buddyLocatorClass>\n"
+" \n"
+"<!-- numBuddies is the number of backup nodes each node maintains. \n"
+"ignoreColocatedBuddies means that each node will *try* to select a buddy on "
+"a different \n"
+"physical host. If not able to do so though, it will fall back to colocated "
+"nodes. -->\n"
+"<buddyLocatorProperties>\n"
+" numBuddies = 1\n"
+" ignoreColocatedBuddies = true\n"
+"</buddyLocatorProperties>\n"
+" \n"
+"<!-- A way to specify a preferred replication group. If specified, we "
+"try to pick a \n"
+"buddy who shares the same pool name (falling back to other buddies if not "
+"available).\n"
+"This allows the sysdmin to hint at backup buddies are picked, so for "
+"example, nodes may be \n"
+"hinted to pick buddies on a different physical rack or power supply for "
+"added fault tolerance. \n"
+"-->\n"
+"<buddyPoolName>myBuddyPoolReplicationGroup</buddyPoolName>\n"
+" \n"
+"<!-- Communication timeout for inter-buddy group organisation messages "
+"(such as assigning \n"
+"to and removing from groups, defaults to 1000. -->\n"
+"<buddyCommunicationTimeout>2000</buddyCommunicationTimeout>\n"
+"\n"
+"<!-- Whether data is removed from old owners when gravitated to a new "
+"owner. \n"
+"Defaults to true. -->\n"
+"<dataGravitationRemoveOnFind>true</dataGravitationRemoveOnFind>\n"
+"\n"
+"<!-- Whether backup nodes can respond to data gravitation requests, or "
+"only the data owner \n"
+"is supposed to respond. Defaults to true. -->\n"
+"<dataGravitationSearchBackupTrees>true</"
+"dataGravitationSearchBackupTrees>\n"
+"\n"
+"<!-- Whether all cache misses result in a data gravitation request. "
+"Defaults to false, \n"
+"requiring callers to enable data gravitation on a per-invocation basis using "
+"the Options API. \n"
+"-->\n"
+"<autoDataGravitation>false</autoDataGravitation>\n"
+"\n"
+"</config>\n"
+"</attribute>"
#. Tag: title
#: Replication.xml:146
#, no-c-format
msgid "Clustered Cache - Using Invalidation"
-msgstr ""
+msgstr "群集缓存 - 使用失效（Invalidation）"
#. Tag: para
#: Replication.xml:147
@@ -482,7 +544,7 @@
"traffic is minimised as invalidation messages are very small compared to "
"replicating updated data, and also that other caches in the cluster look up "
"modified data in a lazy manner, only when needed."
-msgstr ""
+msgstr "如果缓存被配置为失效而不是复制，每次数据有修改时，群集里的其他缓存将收到一条消息来通知它们这个数据已经陈旧且应该从内存逐出。当失效和共享的缓存加载器（参见缓存加载器章节）一起使用时，远程缓存将引用共享缓存加载器来获取修改的数据。这样做的好处是双重的：最小化了网络负载，因为失效消息和复制的数据相比非常小，且群集里的其他缓存只是在需要时才以 lazy 的方式查找修改的数据。"
#. Tag: para
#: Replication.xml:150
@@ -492,7 +554,7 @@
"at the end of a transaction, upon successful commit. This is usually more "
"efficient as invalidation messages can be optimised for the transaction as a "
"whole rather than on a per-modification basis."
-msgstr ""
+msgstr "每次修改发生后（无事务时）或事务结束时成功提交后，失效消息都被发送。这通常更为高效，因为失效消息可以对整个事务进行优化而不是以单次修改为基础。"
#. Tag: para
#: Replication.xml:153
@@ -503,5 +565,5 @@
"cluster receive invalidation messages and have evicted stale data while "
"asynchronous invalidation works in a 'fire-and-forget' mode, where "
"invalidation messages are broadcast but doesn't block and wait for responses."
-msgstr ""
+msgstr "失效可以是同步也可以是异步的，在复制的情况下，同步失效会阻塞至群集里所有缓存都接收到失效消息并已经逐出陈旧数据，而异步失效则以 'fire-and-forget' 的模式工作，其失效消息将进行广播而不会阻塞或等待回应。"
More information about the jboss-cvs-commits
mailing list