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

Wed Oct 1 00:27:34 EDT 2008

Author: ldelima at redhat.com
Date: 2008-10-01 00:27:33 -0400 (Wed, 01 Oct 2008)
New Revision: 78976

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

Modified: projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Transactions.po
===================================================================

--- projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Transactions.po	2008-10-01 02:03:46 UTC (rev 78975)
+++ projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Transactions.po	2008-10-01 04:27:33 UTC (rev 78976)
@@ -9,7 +9,7 @@
 "Project-Id-Version: Transactions\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-30 16:45+1000\n"
+"PO-Revision-Date: 2008-10-01 14:08+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"
@@ -80,7 +80,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 "Os bloqueios podem ser bloqueios de leitura e gravação. Os bloqueios de gravação serializam o acesso de leitura e gravação, enquanto que o bloqueio de leitura apenas serializa o acesso de leitura. Quando o bloqueio de leitura é mantido"
+msgstr "Os bloqueios podem ser bloqueios de leitura e gravação. Os bloqueios de gravação serializam o acesso de leitura e gravação, enquanto que os bloqueios de leitura apenas serializam o acesso de leitura. Quando o bloqueio de gravação é mantido, nenhum outro bloqueio de leitura ou gravação pode ser adquirido. No entanto, para adquirir os bloqueios de gravação, um deles precisa esperar até que todos os bloqueios de leitura sejam liberados. Quando esquematizado simultaneamente, os bloqueios de gravação sempre possuem preferência sobre os bloqueios de leitura. Perceba que (caso ativado) os bloqueios de leitura podem ser atualizados para bloqueios de gravação. "
 
 #. Tag: para
 #: Transactions.xml:22
@@ -95,12 +95,14 @@
 "lock for \"/a/b/n2\". This allows for more concurrency in accessing the "
 "cache."
 msgstr ""
+"O uso dos bloqueios de leitura-gravação auxilia no seguinte senário: considere uma tree com as entradas \"/a/b/n1\" e \"/a/b/n2\". Com os bloqueios de gravação, quando o Tx1 acessa \"/"
+"a/b/n1\", o Tx2 não pode acessar o \"/a/b/n2\" até que o Tx1 tenha completado e liberado seus bloqueios. No entanto, com os bloqueios de leitura-gravação isto é possível, uma vez que o Tx1 adquire os bloqueios de leitura para \"/a/b\" e um bloqueio de leitura-gravação para \"/a/b/n1\". O Tx2 está então apto a adquirir os bloqueios de leitura para \"/a/b\" também, adicionada ao bloqueio de leitura-gravação para \"/a/b/n2\". Isto permite mais simultaneidade no acesso ao cache."
 
 #. Tag: title
 #: Transactions.xml:28
 #, no-c-format
 msgid "Pessimistic locking"
-msgstr ""
+msgstr "Bloqueamento Pessimista"
 
 #. Tag: para
 #: Transactions.xml:29
@@ -109,13 +111,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 "Por padrão, o JBoss Cache usa o bloqueamento pessimista. O Bloqueamento não é exibido diretamente ao usuário. Ao invés disto, o nível de isolamento da transação que fornece um diferente comportamento de bloqueamento é configurável. "
 
 #. Tag: title
 #: Transactions.xml:33
 #, no-c-format
 msgid "Isolation levels"
-msgstr ""
+msgstr "Níveis de isolação"
 
 #. Tag: para
 #: Transactions.xml:34
@@ -126,6 +128,8 @@
 "isolation level of NONE, READ_UNCOMMITTED, READ_COMMITTED, REPEATABLE_READ, "
 "or SERIALIZABLE. REPEATABLE_READ is the default isolation level used."
 msgstr ""
+"O JBoss Cache suporta os seguintes níveis de isolação de transação, parecido com os níveis de isolação ACID do banco de dados. Um usuário pode configurar um nível de isolação de instância do NONE, READ_UNCOMMITTED, READ_COMMITTED, REPEATABLE_READ, "
+"ou SERIALIZABLE. O REPEATABLE_READ é o nível de isolação padrão utilizado."
 
 #. Tag: para
 #: Transactions.xml:39
@@ -134,7 +138,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. Não há necessidade de suporte da transação. Não há bloqueamento neste nível, por exemplo: os usuários terão que gerenciar a integridade dos dados. As implementações não usam bloqueios."
 
 #. Tag: para
 #: Transactions.xml:44
@@ -151,6 +155,11 @@
 "Implementations typically use an exclusive lock for writes while reads don't "
 "need to acquire a lock."
 msgstr ""
+"READ_UNCOMMITTED. Os dados podem ser lidos a qualquer instante enquanto que as operações de gravações são exclusivas. Perceba que este nível não previne a famosa \"leitura dirty\", onde os dados modificados em Tx1 podem ser lidos em Tx2, antes que o Tx1 confirme. Em outras palavras, caso você tenha a seguinte seqüência usando este nível de isolação: programlisting>\n"
+"   Tx1   Tx2\n"
+"  W\n"
+"     R\n"
+"</programlisting>, não procederá com a operação de leitura Tx2."
 
 #. Tag: para
 #: Transactions.xml:50
@@ -160,7 +169,7 @@
 "level prevents the dirty read. But it doesn&#8217;t prevent the so-called "
 "&#8216;non-repeatable read&#8217; where one thread reads the data twice can "
 "produce different results. For example, if you have the following sequence,"
-msgstr ""
+msgstr "READ_COMMITTED. Os dados podem ser lidos a qualquer momento contanto que não haja leitura. Isto previne a leitura dirty, porém não previne a chamada &#8216;non-repeatable read&#8217; onde um segmento lendo um segmento duas vezes poderá produzir resultados diferentes. Por exemplo: caso você possua a seguinte seqüência:"
 
 #. Tag: programlisting
 #: Transactions.xml:51
@@ -180,7 +189,7 @@
 #: Transactions.xml:53
 #, no-c-format
 msgid "where the second read in Tx1 thread will produce different result."
-msgstr ""
+msgstr "onde a segunda leitura no segmento Tx1 produzirá um resultado diferente."
 
 #. Tag: para
 #: Transactions.xml:56
@@ -194,7 +203,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 "As implementações normalmente usam o bloqueio de gravação-leitura, as leituras sucedem adquirindo o bloqueio quando houver aspenas leituras. As gravações terão que esperar atá que não haja mais leituras mantendo o bloqueio e as leituras são bloqueadas adquirindo o bloqueio até que nenhuma gravação mantenha o bloqueio. Normalmente, as leituras liberam o bloqueio de leitura quando finalizados, de forma que a leitura subseqüente aos mesmos dados precisa readquirir um bloqueio de leitura. Isto conduz a leituras sem repetição, onde duas leituras do mesmo dado poderão retornar valores diferentes. Perceba que, a gravação aplica-se independente do estado da transação (se é que isto tem sido confirmado ou não). "
 
 #. Tag: para
 #: Transactions.xml:61
@@ -205,7 +214,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. Os dados podem ser lidos enquanto que não há gravação e vice cersa. Este nível previne \"a leitura sem repetição\", mas isto não previne a chamada \"leitura phantom\", onde novos dados podem ser inseridos na tree a partir de outra transação. Este é o nível de isolação padrão utilizado."
 
 #. Tag: para
 #: Transactions.xml:66
@@ -215,13 +224,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. O acesso aos dados é sincronizado com bloqueios exclusivos. Apenas uma leitura ou gravação pode possuir o bloqueio a qualquer período gerado. Os bloqueios são liberados no final da transação. Isto é considerado fraco para a transação simultânea/segmento e desempenho."
 
 #. Tag: title
 #: Transactions.xml:74
 #, no-c-format
 msgid "Insertion and Removal of Nodes"
-msgstr ""
+msgstr "Inserção e Remoção de Nós"
 
 #. Tag: para
 #: Transactions.xml:75
@@ -238,13 +247,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 "Por padrão, antes de inserir um novo nó numa tree ou remover um nó existente a partir de uma tree, o JBoss Cache tentará adquirir um bloqueio de gravação no nó parent do novo nó. Esta abordagem trata os nós child como parte integral do estado do nó parent. Esta abordagem fornece grandes correções, mas com o custo de menor simultaneidade caso os nós forem freqüentemente adicionados e removidos. Para casos de uso onde estas grandes correções não são significativas, o JBoss Cache fornece a opção de configuração <literal>LockParentForChildInsertRemove</literal>. Caso isto seja configurado para <literal>false</literal>, as inserções e remoções de nós child apenas requerem a aquisição de um <emphasis>bloqueio de leitura</emphasis> no nó parent."
 
 #. Tag: title
 #: Transactions.xml:83
 #, no-c-format
 msgid "Optimistic locking"
-msgstr ""
+msgstr "Bloqueamento otimista"
 
 #. Tag: para
 #: Transactions.xml:84
@@ -257,13 +266,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 "A motivação para o bloqueamento otimista é o melhoramento da simultaneidade. Quando diversos segmentos possuírem muitas disputas para acessar os dados da tree, isto poderá ser ineficiente bloquear as partes da tree - para leitura ou gravação - para a duração completa da transação como realizamos no bloqueamento pessimista. O bloqueamento pessimista permite uma perfeita simultaneidade dos segmentos e transações usando a técnica chamada versão de dados, da qual será descrita adiante. Perceba que os níveis de isolação (caso configurados) são ignorados caso o bloqueamento otimista for ativado."
 
 #. Tag: title
 #: Transactions.xml:88
 #, no-c-format
 msgid "Architecture"
-msgstr ""
+msgstr "Arquitetura"
 
 #. Tag: para
 #: Transactions.xml:89
@@ -276,7 +285,7 @@
 "creates an implicit transaction and commits this transaction when the "
 "invocation completes. Each transaction maintains a transaction workspace, "
 "which contains a copy of the data used within the transaction."
-msgstr ""
+msgstr "O bloqueamento otimista trata todas as chamadas de método como transacional<footnote><para> Devido a este requerimento, você deverá ter sempre um gerenciador de transação configurado quando usando o bloqueamento otimista. </para> </footnote>. mesmo que você não invoque uma chamada com o escopo de uma transação em vigor, o JBoss Cache cria uma transação implícita e confirma esta transação quando a invocação for completada. Cada transação mantém um espaço de trabalho da transação, que contém a cópia de um dado usado com a transação."
 
 #. Tag: para
 #: Transactions.xml:95


