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

Mon Sep 29 02:07:42 EDT 2008

Author: ldelima at redhat.com
Date: 2008-09-29 02:07:42 -0400 (Mon, 29 Sep 2008)
New Revision: 78914

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 04:13:10 UTC (rev 78913)
+++ projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Replication.po	2008-09-29 06:07:42 UTC (rev 78914)
@@ -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-25 15:13+1000\n"
+"PO-Revision-Date: 2008-09-29 16:07+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"
@@ -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 "A replicação assíncrona é rápida (sem chamador realizando o bloqueamento), pois a replicação síncrona requer conhecimento de todos os nós num cluster que eles "
+msgstr "A replicação assíncrona é rápida (sem chamador realizando o bloqueamento), pois a replicação síncrona requer conhecimento de todos os nós num cluster que eles receberam e aplicaram a modificação com êxito (período de ida e vinda). No entanto, quando uma reação retorna com sucesso, o chamador tem absoluta certeza que todas as modificações foram aplicadas em todos os nós, enquanto que isto poderá ser ou não o caso de uma replicação assíncrona. Com a replicação assíncrona, os erros são simplesmente gravados a um log. Mesmo quando usando transações, uma transação pode suceder com êxito, mas a replicação talvez não suceda com êxito em todas as instâncias do <literal>TreeCache</literal>."
 
 #. Tag: title
 #: Replication.xml:28
 #, no-c-format
 msgid "Replicated Caches and Transactions"
-msgstr ""
+msgstr "Transações e Caches Replicados"
 
 #. Tag: para
 #: Replication.xml:29
@@ -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 "Quando usando as transações, a replicação apenas ocorre na vinculação da transação - por exemplo: quando a transação confirmar. Estes resultados na replicação mínima trafegam desde que uma única modificação do sistema operacional trafegar, ao invés de uma série de modificações individuais. Além disto, isto pode ser mais eficiente do que não utilizar outras transações. Outro resultado disto é que se uma transação está para ser retornada, nada será transmitido através do cluster. "
 
 #. Tag: para
 #: Replication.xml:32
@@ -122,12 +122,15 @@
 "\"http://en.wikipedia.org/wiki/Two-phase_commit_protocol\">two phase commit</"
 "ulink> protocol, respectively."
 msgstr ""
+"O JBoss Cache usará tanto uma fase única ou o protocolo <ulink url="
+"\"http://en.wikipedia.org/wiki/Two-phase_commit_protocol\">two phase commit</"
+"ulink> respectivamente, dependendo se é que você está rodando ou não seu cluster num modo assíncrono ou síncrono."
 
 #. Tag: title
 #: Replication.xml:36
 #, no-c-format
 msgid "One Phase Commits"
-msgstr ""
+msgstr "Confirmação de Uma Fase"
 
 #. Tag: para
 #: Replication.xml:37
@@ -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 "Usado quando o seu modo de cache for REPL_ASYNC. Todas as modificações são replicadas em uma chamada única, da qual instrui os caches remotos a aplicar as alterações ao estado dos mesmos em memória local e confirmação local. Errors/Remoções remotas nunca retornam ao originador da transação uma vez que a comunicação é assíncrona. "
 
 #. Tag: title
 #: Replication.xml:43
 #, no-c-format
 msgid "Two Phase Commits"
-msgstr ""
+msgstr "Confirmação de Duas Fases"
 
 #. Tag: para
 #: Replication.xml:44
@@ -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 "Utilizada quando seu modo do cache é REPL_SYNC. Até confirmar sua transação, o JBoss Cache transmite uma chamada preparada que carrega todas as modificações relevantes à transação. Os caches remotos então adquirem os bloqueios locais no estado em memória dos mesmos e aplicam as modificações. Uma vez que todos os caches remotos responderem à chamada preparada, o originador da transação transmite uma confirmação. Isto instrui todos os caches remotos a confirmar os seus dados. Caso algum destes caches falhar em responder à fase preparada, o originador transmite uma reversão."
 
 #. Tag: para
 #: Replication.xml:47
@@ -173,12 +176,14 @@
 "can be forced to be synchronous using the <literal>SyncCommitPhase</literal> "
 "and <literal>SyncRollbackPhase</literal> configuration options."
 msgstr ""
+"Embora que a fase de preparo seja síncrona, as fases de confirmação e reversão são assíncronas. Isto é devido à <ulink url=\"http://java.sun.com/"
+"products/jta/\">Sun's JTA specification</ulink> não especificar como os recursos transacionais devem reagir com as falhas neste estado da transação, além de outros recursos participantes na transação podem ter um estado indeterminado de qualquer forma. Assim como, realizamos com a elevação da comunicação para esta fase da transação. Dito isto, eles podem ser forçados a serem síncronos usando o <literal>SyncCommitPhase</literal> e as opções de configuração <literal>SyncRollbackPhase</literal>."
 
 #. Tag: title
 #: Replication.xml:55
 #, no-c-format
 msgid "Buddy Replication"
-msgstr ""
+msgstr "Replicação Buddy"
 
 #. Tag: para
 #: Replication.xml:56
@@ -189,7 +194,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 "A Replicação Buddy permite você suprimir a replicação de seus dados a todas as instâncias num cluster. Ao invés disto, toda a instância seleciona um ou mais 'buddies' no cluster e apenas replica a estes buddies específicos. Isto ajuda imensamente a escabilidade uma vez que não há mais um impacto no tráfego da rede e memória, toda vez em que outra instância é adicionada a um cluster."
 
 #. Tag: para
 #: Replication.xml:59
@@ -204,7 +209,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 "Um dos casos de usos mais comuns da Replicação Buddy é quando um cache replicado é usado por um container servlet para armazenar os dados da sessão HTTP. Um dos pré-requisitos para a replicação buddy funcionar bem e ser um real benefício, é o uso da <emphasis>session affinity</emphasis>, também conhecida como <emphasis>sticky sessions</emphasis> na fala da replicação da sesssão HTTP. Isto significa que se um certo dado é frequentemente acessado, é preferível que isto seja sempre acessado em uma instância ao invés que uma moda de repetição alternada, uma vez que isto ajuda o cluster do cache otimizar como escolher buddies, onde isto armazena dados e minimiza o tráfego da replicação.   "
 
 #. Tag: para
 #: Replication.xml:62
@@ -212,13 +217,13 @@
 msgid ""
 "If this is not possible, Buddy Replication may prove to be more of an "
 "overhead than a benefit."
-msgstr ""
+msgstr "Caso isto não seja possível, a Replicação Buddy poderá provar ser mais superior do que um benefício."
 
 #. Tag: title
 #: Replication.xml:66
 #, no-c-format
 msgid "Selecting Buddies"
-msgstr ""
+msgstr "Seleção de Buddies"
 
 #. Tag: para
 #: Replication.xml:67
@@ -233,6 +238,9 @@
 "selects the next member in the cluster, as the name suggests, and guarantees "
 "an even spread of buddies for each instance."
 msgstr ""
+"A Replicação de Buddies usa uma instância de um <literal>org.jboss.cache."
+"buddyreplication.BuddyLocator</literal> que contém a lógica usada a selecionar buddies numa rede. Atualmente, o JBoss Cache lança uma única implementação, <literal>org.jboss.cache.buddyreplication."
+"NextMemberBuddyLocator</literal>, que é usada como um padrão caso nenhuma implementação seja fornecida. O <literal>NextMemberBuddyLocator</literal> seleciona o próximo membro no cluster, assim como o nome sugere, e garante ainda a distribuição de buddies por cada instância."
 
 #. Tag: para
 #: Replication.xml:70
@@ -240,7 +248,7 @@
 msgid ""
 "The <literal>NextMemberBuddyLocator</literal> takes in 2 parameters, both "
 "optional."
-msgstr ""
+msgstr "O <literal>NextMemberBuddyLocator</literal>"
 
 #. Tag: para
 #: Replication.xml:73


