[jboss-cvs] JBossAS SVN: r75614 - projects/docs/enterprise/4.3/Transactions/Programmers_Guide/de-DE.

Thu Jul 10 07:40:34 EDT 2008

Author: jdimanos at jboss.com
Date: 2008-07-10 07:40:34 -0400 (Thu, 10 Jul 2008)
New Revision: 75614

Modified:
   projects/docs/enterprise/4.3/Transactions/Programmers_Guide/de-DE/Chapter_03.po
Log:
update

Modified: projects/docs/enterprise/4.3/Transactions/Programmers_Guide/de-DE/Chapter_03.po
===================================================================

--- projects/docs/enterprise/4.3/Transactions/Programmers_Guide/de-DE/Chapter_03.po	2008-07-10 11:09:23 UTC (rev 75613)
+++ projects/docs/enterprise/4.3/Transactions/Programmers_Guide/de-DE/Chapter_03.po	2008-07-10 11:40:34 UTC (rev 75614)
@@ -8,7 +8,7 @@
 "Project-Id-Version: Chapter_03\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2008-06-05 22:51+0000\n"
-"PO-Revision-Date: 2008-07-10 07:24+1000\n"
+"PO-Revision-Date: 2008-07-10 21:39+1000\n"
 "Last-Translator: Jasna Dimanoski <jdimanos at redhat.com>\n"
 "Language-Team:  <de at li.org>\n"
 "MIME-Version: 1.0\n"
@@ -273,6 +273,8 @@
 "logs the decision to commit and attempts to commit the other resources as "
 "well."
 msgstr ""
+"In einigen Fällen kann es nötig sein, nicht in zwei-Phasen Festschreibung gewahre Teilnehmer in eine zwei-Phasen Festschreibungstransaktion einzutragen. Ist nur eine einzige Ressource vorhanden, so besteht keine Notwendigkeit für eine zwei-Phasen Festschreibung. Was aber, wenn mehrere Ressourcen in der Transaktion existieren? In diesem Fall kommt die \"Last "
+"Resource Commit\" Optimierung (LRCO) ins Spiel. Es ist möglich, dass eine einzelne Ressource, die ein-Phasen gewahr ist (d.h. kann nur festschreiben oder zurücksetzen, ohne \"prepare\"), in eine Transaktion mit zwei-Phasen Festschreibung gewahren Ressourcen eingetragen zu sein. Der Koordinator behandelt die ein-Phasen gewahre Ressource etwas anders, und zwar insofern als dass es die \"Prepare\"-Phase zuerst an allen anderen Ressourcen ausführt und - falls es die Transaktion dann festschreiben will - er die Kontrolle an die ein-Phasen gewahre Ressource gibt. Wird festgeschrieben, so protokolliert der Koordinator die Festschreibungsentscheidung und versucht die anderen Ressourcen ebenfalls festzuschreiben."
 
 #. Tag: para
 #: Chapter_03.xml:61
@@ -645,7 +647,7 @@
 "timeout (in seconds) on a per transaction basis such that if the transaction "
 "has not terminated before the timeout expires it will be automatically "
 "rolled back."
-msgstr ""
+msgstr "Standardmäßig leben Transaktionen bis sie durch die Anwendung beendet werden, die sie erstellt hat oder bis ein Fehler auftritt. Es ist jedoch möglich, einen Timeout (in Sekunden) auf pro-Transaktionsbasis einzustellen, so dass - falls die Transaktion nicht endet ehe der Timeout abläuft - eine automatische Zurücksetzung erfolgt."
 
 #. Tag: para
 #: Chapter_03.xml:140
@@ -660,6 +662,10 @@
 "property <literal>com.arjuna.ats.arjuna.coordinator.defaultTimeout</"
 "literal>. Unless changed the default value is 60 seconds."
 msgstr ""
+"In <emphasis>TxCore</emphasis> wird der Timeout-Wert als ein Parameter zum <classname>AtomicAction</classname>-Konstruktor geliefert. Wird ein "
+"<literal>AtomicAction.NO_TIMEOUT</literal>-Wert bereitgestellt (der Standard) dann erfolgt für die Transaktion kein automatischer Timeout. Jeder andere positive Wert wird als Timeout für die Transaktion (in Sekunden) angenommen. Ein Wert von Null"
+"wird als allgemeiner Standard-Timeout angenommen, der durch die Property <literal>com.arjuna.ats.arjuna.coordinator.defaultTimeout</"
+"literal> geliefert werden kann. Falls er nicht geändert wird, so beträgt der Standardwert 60 Sekunden."
 
 #. Tag: para
 #: Chapter_03.xml:142
@@ -679,6 +685,10 @@
 "transaction times out. This has the advantage of terminating transactions "
 "early, but may suffer from continually rescheduling the reaper thread."
 msgstr ""
+"Wird eine Transaktion der höchsten Ebene mit einem nicht-Null Timeout erstellt, so wird sie zurückgesetzt, wenn sie nicht innerhalb der festgelegten Sekundenzahl beendet wird. <emphasis>JBossTS</emphasis> verwendet einen separaten \"Reaper-Thread\", der alle lokal erstellten Transaktionen überwacht und deren Zurücksetzen erzwingt wenn deren Timeouts ablaufen. Um zu verhindern, dass dieser Thread Anwendungszeit verbraucht, läuft er nur periodisch. Die Standard-Prüfperiode sind 120000 Millisekunden, aber dies kann durch Einstellen der <literal>com."
+"arjuna.ats.arjuna.coordinator.txReaperTimeout</literal>-Property-Variable auf einen anderen Wert in Mikrosekunden geändert werden. Alternativ, falls <literal>com."
+"arjuna.ats.arjuna.coordinator.txReaperMode</literal> auf "
+"<literal>DYNAMIC</literal> eingestellt ist, erwacht der \"Transaction-Reaper\" beim Timeout jeder Transaktion. Dies hat den Vorteil, das Transaktionen früher beendet werden, kann aber zur ständigen Neuterminierung des Reaper Threads führen."
 
 #. Tag: para
 #: Chapter_03.xml:144
@@ -693,4 +703,8 @@
 "emphasis>, or <literal>com.arjuna.ats.jts.defaultTimeout</literal> if using "
 "<emphasis>ArjunaJTS</emphasis>, to the required timeout value in seconds."
 msgstr ""
+"Wird ein Wert von 0 als Timeout für eine Transaktion der höchsten Ebene festgelegt (oder kein Timeout festgelegt), dann macht <emphasis>JBossTS</emphasis> keinen Timeout bei der Transaktion geltend, d.h. sie kann unbeschränkt laufen. Dieser Standard-Timeout kann durch Einstellen der "
+"<literal>com.arjuna.ats.arjuna.coordinator.defaultTimeout</literal> Property-Variable außer Kraft und zum benötigten Timeout-Wert in Sekunden gesetzt werden, wenn <emphasis>ArjunaCore</emphasis> oder <emphasis>ArjunaJTS</"
+"emphasis> oder <literal>com.arjuna.ats.jts.defaultTimeout</literal> verwendet wird, wenn "
+"<emphasis>ArjunaJTS</emphasis> benutzt wird."
 


