[jboss-cvs] JBossAS SVN: r75142 - projects/docs/enterprise/4.3/Transactions/Programmers_Guide/pt-BR.

jboss-cvs-commits at lists.jboss.org jboss-cvs-commits at lists.jboss.org
Fri Jun 27 00:15:44 EDT 2008


Author: ldelima at redhat.com
Date: 2008-06-27 00:15:44 -0400 (Fri, 27 Jun 2008)
New Revision: 75142

Modified:
   projects/docs/enterprise/4.3/Transactions/Programmers_Guide/pt-BR/Chapter_04.po
Log:
translation ongoing

Modified: projects/docs/enterprise/4.3/Transactions/Programmers_Guide/pt-BR/Chapter_04.po
===================================================================
--- projects/docs/enterprise/4.3/Transactions/Programmers_Guide/pt-BR/Chapter_04.po	2008-06-27 03:27:34 UTC (rev 75141)
+++ projects/docs/enterprise/4.3/Transactions/Programmers_Guide/pt-BR/Chapter_04.po	2008-06-27 04:15:44 UTC (rev 75142)
@@ -8,7 +8,7 @@
 "Project-Id-Version: Chapter_04\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2008-06-05 22:51+0000\n"
-"PO-Revision-Date: 2008-06-27 13:27+1000\n"
+"PO-Revision-Date: 2008-06-27 14:15+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"
@@ -48,7 +48,7 @@
 "however, the constructor transaction commits but is nested because some "
 "other transaction started prior to object creation is running, then the "
 "state will be written only if all of the parent transactions commit."
-msgstr "Os exemplos demonstrados neste manual tem utilizado transações na implementação de construtores para novos objetos de persistência. Isto é discutido uma vez que garante a propagação correta deste estado do objeto para o armazemento do objeto. Lembre-se de que o estado de um objeto persistente modificado é apenas gravado no armazenamento do objeto quando a transação de nível superior for confirmada. Desta forma, se uma transação do construtor for de nível superior e confirmada, então o mais novo objeto criado é gravado no armazenamento e será imediatamente disponível."
+msgstr "Os exemplos demonstrados neste manual tem utilizado transações na implementação de construtores para novos objetos de persistência. Isto é discutido uma vez que garante a propagação correta deste estado do objeto para o armazenamento do objeto. Lembre-se de que o estado de um objeto persistente modificado é apenas gravado no armazenamento do objeto quando a transação de nível superior for confirmada. Desta forma, se uma transação do construtor for de nível superior e confirmada, então o mais novo objeto criado é gravado no armazenamento e será imediatamente disponível. No entanto, se a transação do construtor for confirmada, mas estiver aninhada devido a algumas outras transações iniciadas antecipadamente a rodagem da criação do objeto, então o estado será gravado apenas se todas as transações parent estiverem confirmadas."
 
 #. Tag: para
 #: Chapter_04.xml:16
@@ -59,13 +59,13 @@
 "transaction is active when the object is created then its state will not be "
 "saved to the store until the next time the object is modified under the "
 "control of some transaction."
-msgstr ""
+msgstr "Por outro lado, caso o construtor não use transações, o aparecimento de inconsistências no sistema será possível. Por exemplo, caso não hajam transações ativadas quando o objeto for criado, então o próprio estado não será salvo ao armazenamento até a próxima vez em que o objeto seja modificado, sob o controle de algumas transações. "
 
 #. Tag: para
 #: Chapter_04.xml:18
 #, no-c-format
 msgid "Consider this simple example:"
-msgstr ""
+msgstr "Considere a simples amostra abaixo:"
 
 #. Tag: programlisting
 #: Chapter_04.xml:20
@@ -113,12 +113,14 @@
 "been saved at the time it was constructed and this inconsistency could not "
 "arise."
 msgstr ""
+"Neste caso, os dois objetos são criados fora do controle de ação de nível superior A. O <literal>obj1</literal> é um novo objeto enquanto que o <literal>obj2</literal> é um objeto antigo existente. Quando a operação relembrar do <literal>obj2</"
+"literal> for invocada, o objeto será ativado e Uid da <literal>obj1</literal> relembrado. Uma vez que esta ação for confirmada o estado persistente do <literal>obj2</literal> poderá conter agora o Uid do objeto. No entanto, o estado do <literal>obj1</literal> por si próprio, não foi salvo uma vez que ele não foi manipulado sob o controle de qualquer ação. Na realidade, isto nunca será salvo a não ser que ele seja modificado sob o controle de algumas ações mais tarde no aplicativo. Porém, se o construtor tenha usado uma ação atômica, o estado do <literal>obj1</literal> poderia ter sido salvo automaticamente no período em que isto foi construído, e esta consistência jamais apareceria."
 
 #. Tag: title
 #: Chapter_04.xml:26
 #, no-c-format
 msgid "More on save_state and restore_state"
-msgstr ""
+msgstr "Um pouco mais a respeito do save_state e restore_state"
 
 #. Tag: para
 #: Chapter_04.xml:28
@@ -131,6 +133,8 @@
 "therefore, that all of the variables saved by save_state are correctly "
 "initialised."
 msgstr ""
+"O <emphasis>TxCore</emphasis> poderá invocar a operação <command>save_state</"
+"command> do usuário definido de um objeto efetivamente a qualquer período durante o ciclo de vida de um objeto incluído durante a construção da execução do corpo de um construtor do objeto (particularmente se isto usa as ações atômicas). Isto é importante e portanto, todas aquelas variáveis salvas save_state são corretamente inicializadas."
 
 #. Tag: para
 #: Chapter_04.xml:30




More information about the jboss-cvs-commits mailing list