[jboss-cvs] JBossAS SVN: r79054 - projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Fri Oct 3 03:01:14 EDT 2008
Author: ldelima at redhat.com
Date: 2008-10-03 03:01:14 -0400 (Fri, 03 Oct 2008)
New Revision: 79054
Modified:
projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Basic_api.po
projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Book_Info.po
projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Introduction.po
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/Transactions.po
Log:
proofread in progress
Modified: projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Basic_api.po
===================================================================
--- projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Basic_api.po 2008-10-03 06:46:23 UTC (rev 79053)
+++ projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Basic_api.po 2008-10-03 07:01:14 UTC (rev 79054)
@@ -9,7 +9,7 @@
"Project-Id-Version: Basic_api\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2008-09-21 04:43+0000\n"
-"PO-Revision-Date: 2008-09-17 09:54+1000\n"
+"PO-Revision-Date: 2008-10-03 15:14+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"
@@ -125,7 +125,7 @@
#: Basic_api.xml:22
#, no-c-format
msgid "The resulting tree looks like this:"
-msgstr "O tree resultante parece-se com:"
+msgstr "A tree resultante parece-se com:"
#. Tag: title
#: Basic_api.xml:26
@@ -281,7 +281,7 @@
"the node's map, overwriting existing keys and values. Content that is not in "
"the new map remains in the node's map."
msgstr ""
-"Existem dois put() methods<footnote><para> Além disso, os métodos deles de "
+"Existem dois métodos put() <footnote><para> Além disso, os métodos deles de "
"ajuda equivalente usam uma Seqüência como o nome do nó.</para> </footnote> : "
"<literal>put(Fqn node, Object key, Object key)</literal> e <literal>put(Fqn "
"node, Map values)</literal>. "
@@ -313,9 +313,9 @@
"navigation, the latter returns the value for the given key for a node."
msgstr ""
"Os métodos get são: <literal>get(Fqn node)</literal> e <literal>get(Fqn "
-"node, Object key)</literal>. O primeiro retorna a um Node<footnote><para> "
+"node, Object key)</literal>. O primeiro retorna a um objeto Node<footnote><para> "
"Isto é basicamente usado internamente e poderemos remover o acesso público "
-"ao Nó na versão futura. </para> </footnote> objeto, permitindo a navegação "
+"ao Nó na versão futura. </para> </footnote>, permitindo a navegação "
"direta. O segundo retorna o valor para a tecla gerada para um nó."
#. Tag: para
@@ -329,3 +329,4 @@
"Além disso, o <literal>TreeCache</literal> possui um número de getters e "
"setters. Uma vez que o API poderá sofrer alteração a qualquer instante, "
"recomendamos o Javadoc para a informação up-to-date."
+
Modified: projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Book_Info.po
===================================================================
--- projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Book_Info.po 2008-10-03 06:46:23 UTC (rev 79053)
+++ projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Book_Info.po 2008-10-03 07:01:14 UTC (rev 79054)
@@ -9,7 +9,7 @@
"Project-Id-Version: Book_Info\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2008-09-21 04:43+0000\n"
-"PO-Revision-Date: 2008-09-26 07:43+1000\n"
+"PO-Revision-Date: 2008-10-03 10:44+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"
@@ -27,13 +27,13 @@
#: Book_Info.xml:6
#, no-c-format
msgid "for Use with JBoss Enterprise Application Platform 4.3"
-msgstr "para uso com o Aplicativo da Plataforma JBoss Enterprise 4.3 "
+msgstr "para uso com a Plataforma do Aplicativo JBoss Enterprise 4.3 "
#. Tag: para
#: Book_Info.xml:12
#, no-c-format
msgid "This book is about the JBoss Cache Tree Cache."
-msgstr "Este livro fala a respeito do JBoss Cache Tree Cache."
+msgstr "Este livro descreve o Tree Cache do JBoss Cache."
#. Tag: holder
#: Book_Info.xml:26
Modified: projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Introduction.po
===================================================================
--- projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Introduction.po 2008-10-03 06:46:23 UTC (rev 79053)
+++ projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Introduction.po 2008-10-03 07:01:14 UTC (rev 79054)
@@ -9,7 +9,7 @@
"Project-Id-Version: Introduction\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-24 16:11+1000\n"
+"PO-Revision-Date: 2008-10-03 11:27+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"
@@ -113,7 +113,7 @@
"literal>, but is a vital requirement for <literal>PojoCache</literal> (as we "
"will see in the separate <literal>PojoCache</literal> documentation)."
msgstr ""
-"A primeira versão do <literal>TreeCache</literal> era essencialmente um único <literal>HashMap</literal> daquele replicado. No entanto, foi optado pelo cache tree estruturado, pelos seguintes motivos: (a) isto é mais flexível e eficiente; e (b) o tree pode sempre ser reduzido a um mapa e, com isto, oferecendo ambas possibilidades. A discussão de eficiência foi dirigida pelas preocupações sobre a replicação à frente e era a respeito de que um valor por conta próprio pode ser preferencialmente um objeto sofisticado com a agregação apontando a outros objetos ou um objeto contento muitos campos. Uma pequena mudança no objeto pode, então, realizar o trigger em todo o (possivelmente o fechamento transitivo sobre o gráfico do objeto) a ser serializado e propagado a outros nós no cluster. Com uma tree, apenas os nós modificados na mesma precisam ser serializados e propagados. Isto não é na necessidade uma preocupação para o <literal>TreeCache</"
+"A primeira versão do <literal>TreeCache</literal> era essencialmente um único <literal>HashMap</literal> daquele replicado. No entanto, optou-se pelo cache tree estruturado, pelos seguintes motivos: (a) isto é mais flexível e eficiente; e (b) a tree pode sempre ser reduzida a um mapa e, com isto, oferecendo ambas possibilidades. A discussão de eficiência foi dirigida pelas preocupações sobre a replicação sobrecarregada e tratava-se de: um valor próprio pode ser preferencialmente um objeto sofisticado com a agregação apontando a outros objetos ou um objeto contento muitos campos. Uma pequena mudança no objeto pode, então, realizar o trigger em todo o objeto (possivelmente o fechamento transitivo sobre o gráfico do objeto) a ser serializado e propagado a outros nós no cluster. Com uma tree, apenas os nós modificados na mesma precisam ser serializados e propagados. Na realidade, isto não é uma preocupação para o <literal>TreeCache</"
"literal>, mas uma solicitação vital para o <literal>PojoCache</literal> (conforme veremos na documentação <literal>PojoCache</literal> separada)."
#. Tag: para
@@ -129,7 +129,7 @@
"replication traffic and overhead. For example, if a caller makes 100 "
"modifications and then rolls back the transaction, we will not replicate "
"anything, resulting in no network traffic."
-msgstr "Quando uma alteração é realizada ao <literal>TreeCache</literal> e aquela alteração é feita no contexto da alteração de uma transação, então deferiremos a replicação das alterações até que a transação confirme com êxito. Todas as modificações são mantidas numa lista associada com a transação para o chamador. Quando a transação confirmar, replicaremos as alterações. Do contrário, (numa reversão) nós simplesmente desfaremos as alterações localmente e liberaremos qualquer bloqueio, resultando em zero o tráfico de replicação e adiante. Por exemplo, se um chamador realizar 100 modificações e então reverter a transação, não replicaremos nada, resultando em nenhum tráfego da rede."
+msgstr "Quando uma alteração é realizada ao <literal>TreeCache</literal> e a mesma é feita no contexto da alteração de uma transação, deferimos a replicação das alterações até que a transação confirme com êxito. Todas as modificações são mantidas numa lista associada com a transação para o chamador. Quando a transação confirmar, replicaremos as alterações. Do contrário, (numa reversão) nós simplesmente desfaremos as alterações localmente e liberaremos qualquer bloqueio, resultando em zero o tráfico de replicação e adiante. Por exemplo, se um chamador realizar 100 modificações e então reverter a transação, não replicaremos nada, resultando em nenhum tráfego da rede."
#. Tag: para
#: Introduction.xml:33
@@ -142,7 +142,7 @@
"transaction can be thought of as analogous as running with auto-commit "
"switched on in JDBC terminology, where each operation is committed "
"automatically."
-msgstr "Caso o chamador não possui uma transação associada com isto (e o nível de isolação for NONE - veremos mais a respeito disto adiante), replicaremos após cada modificação, por exemplo: no caso acima enviaríamos 100 mensagens, além de uma mensagem adicional para a reversão. Neste contexto, a execução sem uma transação pode ser pensada como um análogo uma vez que rodando com a confirmação automática ativada em cada terminologia, onde cada operação é confirmada automaticamente. "
+msgstr "Caso o chamador não possui uma transação associada com isto (e o nível de isolação for NONE - veremos mais a respeito disto adiante), realizaremos a replicação após cada modificação, por exemplo: no caso acima enviaríamos 100 mensagens, além de uma mensagem adicional para a reversão. Neste contexto, a execução sem uma transação pode ser pensada como um análogo uma vez que executada com a confirmação automática ativada em cada terminologia, onde cada operação é confirmada automaticamente. "
#. Tag: para
#: Introduction.xml:36
@@ -153,7 +153,7 @@
"Several <literal>TransactionManagerLookup</literal> implementations are "
"provided for popular transaction managers, including a "
"<literal>DummyTransactionManager</literal> for testing."
-msgstr "Existe um API para realizar o plugging em diferentes gerenciadores de transação: tudo o que isto solicita é obter a transação associada com o segmento do chamador. Diversas implementações <literal>TransactionManagerLookup</literal> são fornecidas para gerenciadores de transações populares, incluindo um <literal>DummyTransactionManager</literal> para testes."
+msgstr "Existe um API para realizar o plugging em diferentes gerenciadores de transação: tudo o que isto solicita é a obtenção da transação associada com o segmento do chamador. Diversas implementações <literal>TransactionManagerLookup</literal> são fornecidas para gerenciadores de transações populares, incluindo um <literal>DummyTransactionManager</literal> para testes."
#. Tag: para
#: Introduction.xml:39
@@ -169,9 +169,9 @@
"an object for which we do not yet have a lock (this would result in too high "
"an overhead for messaging)."
msgstr ""
-"Finalmente, usamos o bloqueamento pessimista do cache pelo padrão, com o bloqueamento otimista como uma opção configurável. Podemos configurar a política de bloqueamento local correspondente aos níveis de isolação de transação de estilo de banco de dados, por exemplo:SERIALIZABLE, REPEATABLE, READ_COMMITTED, "
+"Finalmente, usamos o bloqueamento pessimista do cache pelo padrão, com o bloqueamento otimista como uma opção configurável. Podemos configurar a política de bloqueamento local correspondente aos níveis de isolação de transação de estilo de banco de dados, por exemplo: SERIALIZABLE, REPEATABLE, READ_COMMITTED, "
"READ_UNCOMMITTED e NONE com o bloqueamento pessimista. Falaremos mais a respeito dos níveis de isolação da transação à frente. Perceba que o nível de isolação do cluster é READ-"
-"UNCOMMITTED pelo padrão uma vez que não adquirimos um bloqueio de cluster quando tocando um objeto pelo qual ainda não bloqueamos (isto poderá resultar em uma elevação muito alta para mensagens)."
+"UNCOMMITTED pelo padrão, uma vez que não adquirimos um bloqueio de cluster quando tocando um objeto pelo qual ainda não bloqueamos (isto poderá resultar em uma elevação bem potente para mensagens)."
#. Tag: para
#: Introduction.xml:42
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-10-03 06:46:23 UTC (rev 79053)
+++ projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Replication.po 2008-10-03 07:01:14 UTC (rev 79054)
@@ -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-30 11:24+1000\n"
+"PO-Revision-Date: 2008-10-03 16:09+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"
@@ -177,7 +177,7 @@
"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>."
+"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 poderem possuir 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
@@ -209,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 "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. "
+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 é freqüentemente 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
@@ -351,7 +351,7 @@
"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> - força todos os caches remotos que possuem os dados ouu retém os backups para os dados removerem aqueles dados, portanto fazendo uma solicitação de cache ao novo proprietário dos dados. Caso configurado para <literal>false</"
+"<literal>dataGravitationRemoveOnFind</literal> - força todos os caches remotos que possuem os dados ou retém os backups para os dados removerem aqueles dados, portanto fazendo uma solicitação de cache ao novo proprietário dos dados. Caso configurado para <literal>false</"
"literal> uma remoção é transferida ao invés de ser removida, de forma que qualquer estado persistente nos carregadores do cache serão mantidos. Isto é útil caso você tenha um configurado carregador de cache compartilhado. Padrões para <literal>true</literal>."
#. Tag: para
@@ -363,7 +363,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 "<literal>dataGravitationSearchBackupTrees</literal> - Pergunta às instâncias remotas a buscar através de seus backups assim como as trees de dados principais. Padões para <literal>true</literal>. O efeito resultae é que se isto for <literal>true</literal>, então os nós de backup podem responder às solicitações de gravitação de dados em adicição aos proprietários de dados."
+msgstr "<literal>dataGravitationSearchBackupTrees</literal> - Pergunta às instâncias remotas a buscar através de seus backups assim como as trees de dados principais. Padrões para <literal>true</literal>. O efeito resultante é que se isto for <literal>true</literal>, então os nós de backup podem responder às solicitações de gravitação de dados em adição aos proprietários de dados."
#. Tag: para
#: Replication.xml:109
@@ -543,7 +543,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 "Caso um cache seja configurado para a validação ao invés da replicação, cada dado de tempo é alterado num cache, outros caches num cluster receberão uma mensagem informando-os que seus dados são agora obsoletos e deverão ser removidos da memória. Quando a invalidação for usada com um carregador de cache compartilhado (consulte o capítulo de Carregadores de Cache) poderá levar aos caches remotos a referirem-se ao carregador de cache compartilhado para recuperar os dados modificados. O benefício disto é duplicado: o tráfego da rede é minimizado como as mensagens de invalidação são bem pequenas comparadas à replicação de dados atualizados e também os demais caches no cluster observarão poucas vezes os dados modificados, apenas quando necessário."
+msgstr "Caso um cache seja configurado para a validação ao invés da replicação, cada dado de tempo é alterado num cache, outros caches num cluster receberão uma mensagem informando-os que seus dados são agora obsoletos e deverão ser removidos da memória. Quando a invalidação for usada com um carregador de cache compartilhado (consulte o capítulo de Carregadores de Cache), isto poderá levar aos caches remotos a referirem-se ao carregador de cache compartilhado para recuperar os dados modificados. O benefício disto é duplicado: o tráfego da rede é minimizado como as mensagens de invalidação são bem pequenas comparadas à replicação de dados atualizados e também os demais caches no cluster observarão poucas vezes os dados modificados, apenas quando necessário."
#. Tag: para
#: Replication.xml:145
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-03 06:46:23 UTC (rev 79053)
+++ projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/pt-BR/Transactions.po 2008-10-03 07:01:14 UTC (rev 79054)
@@ -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-10-03 10:35+1000\n"
+"PO-Revision-Date: 2008-10-03 16: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"
@@ -36,7 +36,7 @@
"JBoss Cache uses a pessimistic locking scheme by default to prevent "
"concurrent access to the same data. Optimistic locking may alternatively be "
"used, and is discussed later."
-msgstr "O JBossCache usa um esquema de bloqueamento pessimista por padrão para prevenir o acesso simultâneo a alguns dados. O bloqueamento otimista poderá ser usado como uma alternativa e discutido e será discutido adiante."
+msgstr "O JBossCache usa um esquema de bloqueamento pessimista por padrão para prevenir o acesso simultâneo a alguns dados. O bloqueamento otimista poderá ser usado como uma alternativa e será discutido adiante."
#. Tag: title
#: Transactions.xml:12
@@ -203,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 "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). "
+msgstr "As implementações normalmente usam o bloqueio de gravação-leitura, as leituras sucedem adquirindo o bloqueio quando houver apenas 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
@@ -214,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 "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."
+msgstr "REPEATABLE_READ. Os dados podem ser lidos enquanto que não há gravação e vice versa. 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
More information about the jboss-cvs-commits
mailing list