[jboss-cvs] JBossAS SVN: r78937 - projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR.

[jboss-cvs-commits at lists.jboss.org]

Author: ldelima at redhat.com
Date: 2008-09-29 19:22:12 -0400 (Mon, 29 Sep 2008)
New Revision: 78937

Modified:
   projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Replication.po
Log:
proofread in progress

Modified: projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Replication.po
===================================================================
--- projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Replication.po	2008-09-29 23:12:32 UTC (rev 78936)
+++ projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Replication.po	2008-09-29 23:22:12 UTC (rev 78937)
@@ -9,7 +9,7 @@
 "Project-Id-Version: Replication\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2008-09-21 04:44+0000\n"
-"PO-Revision-Date: 2008-09-29 16:07+1000\n"
+"PO-Revision-Date: 2008-09-30 09:22+1000\n"
 "Last-Translator: Leticia de Lima <ldelima at redhat.com>\n"
 "Language-Team: Brazilian Portuguese <en at li.org>\n"
 "MIME-Version: 1.0\n"
@@ -245,10 +245,11 @@
 #. Tag: para
 #: Replication.xml:70
 #, no-c-format
+#, fuzzy
 msgid ""
 "The <literal>NextMemberBuddyLocator</literal> takes in 2 parameters, both "
 "optional."
-msgstr "O <literal>NextMemberBuddyLocator</literal>"
+msgstr "O <literal>NextMemberBuddyLocator</literal> leva em 2 parâmetros, ambos opcionais."
 
 #. Tag: para
 #: Replication.xml:73
@@ -256,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> - especifica quantos buddies cada instância deve selecionar para retorna os seus dados para isto."
 
 #. Tag: para
 #: Replication.xml:76
@@ -266,13 +267,13 @@
 "<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> -significa que cada instância <emphasis>tentará</emphasis> selecionar um buddy em um hospedeiro físico. Caso não seja apto a fazer isto com a "
 
 #. Tag: title
 #: Replication.xml:83
 #, no-c-format
 msgid "BuddyPools"
-msgstr ""
+msgstr "BuddyPools"
 
 #. Tag: para
 #: Replication.xml:84
@@ -290,12 +291,23 @@
 "<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 ""
+"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. "
+"Think of this as an 'exclusive club membership' where when selecting "
+"buddies, <literal>BuddyLocator</literal>s would try and select buddies "
+"sharing the same buddy pool name. This allows system administrators a degree "
+"of flexibility and control over how buddies are selected. For example, a "
+"sysadmin may put two instances on two separate physical servers that may be "
+"on two separate physical racks in the same buddy pool. So rather than "
+"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."
 
 #. Tag: title
 #: Replication.xml:90
 #, no-c-format
 msgid "Failover"
-msgstr ""
+msgstr "Failover"
 
 #. Tag: para
 #: Replication.xml:91
@@ -307,6 +319,11 @@
 "any other random cache instance in the cluster. This is where a concept of "
 "Data Gravitation comes in."
 msgstr ""
+"In the unfortunate event of an instance crashing, it is assumed that the "
+"client connecting to the cache (directly or indirectly, via some other "
+"service such as HTTP session replication) is able to redirect the request to "
+"any other random cache instance in the cluster. This is where a concept of "
+"Data Gravitation comes in."
 
 #. Tag: para
 #: Replication.xml:94
@@ -320,6 +337,13 @@
 "other instances will still be able to access this data by asking the cluster "
 "to search through their backups for this data."
 msgstr ""
+"Data Gravitation is a concept where if a request is made on a cache in the "
+"cluster and the cache does not contain this information, it then asks other "
+"instances in the cluster for the data. If even this fails, it would "
+"(optionally) ask other instances to check in the backup data they store for "
+"other caches. This means that even if a cache containing your session dies, "
+"other instances will still be able to access this data by asking the cluster "
+"to search through their backups for this data."
 
 #. Tag: para
 #: Replication.xml:97
@@ -331,6 +355,11 @@
 "is used, the affinity should now be to this new cache instance which has "
 "just <emphasis>taken ownership</emphasis> of this data."
 msgstr ""
+"Once located, this data is then transferred to the instance which requested "
+"it and is added to this instance's data tree. It is then (optionally) "
+"removed from all other instances (and backups) so that if session affinity "
+"is used, the affinity should now be to this new cache instance which has "
+"just <emphasis>taken ownership</emphasis> of this data."
 
 #. Tag: para
 #: Replication.xml:100
@@ -339,6 +368,8 @@
 "Data Gravitation is implemented as an interceptor. The following (all "
 "optional) configuration properties pertain to data gravitation."
 msgstr ""
+"Data Gravitation is implemented as an interceptor. The following (all "
+"optional) configuration properties pertain to data gravitation."
 
 #. Tag: para
 #: Replication.xml:103
@@ -351,6 +382,12 @@
 "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> - forces all remote caches "
+"that own the data or hold backups for the data to remove that data, thereby "
+"making the requesting cache the new data owner. If set to <literal>false</"
+"literal> an evict is broadcast instead of a remove, so any state persisted "
+"in cache loaders will remain. This is useful if you have a shared cache "
+"loader configured. Defaults to <literal>true</literal>."
 
 #. Tag: para
 #: Replication.xml:106
@@ -362,6 +399,11 @@
 "<literal>true</literal> then backup nodes can respond to data gravitation "
 "requests in addition to data owners."
 msgstr ""
+"<literal>dataGravitationSearchBackupTrees</literal> - Asks remote instances "
+"to search through their backups as well as main data trees. Defaults to "
+"<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."
 
 #. Tag: para
 #: Replication.xml:109
@@ -375,12 +417,19 @@
 "literal> is <literal>true</literal> this <literal>Option</literal> is "
 "unnecessary."
 msgstr ""
+"<literal>autoDataGravitation</literal> - Whether data gravitation occurs for "
+"every cache miss. My default this is set to <literal>false</literal> to "
+"prevent unnecessary network calls. Most use cases will know when it may need "
+"to gravitate data and will pass in an <literal>Option</literal> to enable "
+"data gravitation on a per-invocation basis. If <literal>autoDataGravitation</"
+"literal> is <literal>true</literal> this <literal>Option</literal> is "
+"unnecessary."
 
 #. Tag: title
 #: Replication.xml:116
 #, no-c-format
 msgid "Implementation"
-msgstr ""
+msgstr "Implementation"
 
 #. Tag: title
 #: Replication.xml:119
@@ -389,12 +438,14 @@
 "Class diagram of the classes involved in buddy replication and how they are "
 "related to each other"
 msgstr ""
+"Class diagram of the classes involved in buddy replication and how they are "
+"related to each other"
 
 #. Tag: title
 #: Replication.xml:130
 #, no-c-format
 msgid "Configuration"
-msgstr ""
+msgstr "Configuration"
 
 #. Tag: programlisting
 #: Replication.xml:132
@@ -524,7 +575,7 @@
 #: Replication.xml:141
 #, no-c-format
 msgid "Clustered Cache - Using Invalidation"
-msgstr ""
+msgstr "Clustered Cache - Using Invalidation"
 
 #. Tag: para
 #: Replication.xml:142
@@ -540,6 +591,15 @@
 "replicating updated data, and also that other caches in the cluster look up "
 "modified data in a lazy manner, only when needed."
 msgstr ""
+"If a cache is configured for invalidation rather than replication, every "
+"time data is changed in a cache other caches in the cluster receive a "
+"message informing them that their data is now stale and should be evicted "
+"from memory. Invalidation, when used with a shared cache loader (see chapter "
+"on Cache Loaders) would cause remote caches to refer to the shared cache "
+"loader to retrieve modified data. The benefit of this is twofold: network "
+"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."
 
 #. Tag: para
 #: Replication.xml:145
@@ -550,6 +610,10 @@
 "efficient as invalidation messages can be optimised for the transaction as a "
 "whole rather than on a per-modification basis."
 msgstr ""
+"Invalidation messages are sent after each modification (no transactions), or "
+"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."
 
 #. Tag: para
 #: Replication.xml:148
@@ -561,4 +625,9 @@
 "asynchronous invalidation works in a 'fire-and-forget' mode, where "
 "invalidation messages are broadcast but doesn't block and wait for responses."
 msgstr ""
+"Invalidation too can be synchronous or asynchronous, and just as in the case "
+"of replication, synchronous invalidation blocks until all caches in the "
+"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."