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

[jboss-cvs-commits at lists.jboss.org]

Author: jdimanos at jboss.com
Date: 2008-07-09 07:49:34 -0400 (Wed, 09 Jul 2008)
New Revision: 75542

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-09 11:36:37 UTC (rev 75541)
+++ projects/docs/enterprise/4.3/Transactions/Programmers_Guide/de-DE/Chapter_03.po	2008-07-09 11:49:34 UTC (rev 75542)
@@ -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-09 07:55+1000\n"
+"PO-Revision-Date: 2008-07-09 21:42+1000\n"
 "Last-Translator: Jasna Dimanoski <jdimanos at redhat.com>\n"
 "Language-Team:  <de at li.org>\n"
 "MIME-Version: 1.0\n"
@@ -66,6 +66,9 @@
 "instance of this class associated with it, and application programmers can "
 "provide their own implementations on a per transaction basis."
 msgstr ""
+"In einer Anwendung mit mehreren Threads können mehrere Threads während ihrer Lebensdauer mit einer Transaktion assoziiert werden, d.h. die Threads teilen sich den Kontext. Zusätzlich ist es möglich, dass - wenn ein Thread eine Transaktion beendet - andere Threads weiterhin aktiv innerhalb davon sind. In einer distribuierten Umgebung kann es schwierig sein zu garantieren, dass alle Threads mit einer Transaktion fertig sind, wenn diese beendet wird. Standardmäßig gibt <emphasis>TxCore</emphasis> eine Warnung heraus, wenn ein Thread eine Transaktion beendet wenn andere Threads darin noch aktiv sind - allerdings wird die Fortsetzung der Beendigung nichtsdestotrotz erlaubt. Es sind andere Lösungen für dieses Problem möglich, z.B. Sperren des die Transaktion beendenden Threads, bis alle anderen Threads sich vom Transaktionkontext disassoziiert haben. Daher liefert "
+"<emphasis>TxCore</emphasis> die <classname>com.arjuna.ats.arjuna."
+"coordinator.CheckedAction</classname>-Klasse, die es gestattet, die Richtlinien für die Thread-/Transaktionsbeendigung außer Kraft zu setzen. Jede Transaktion hat eine Instanz dieser Klasse mit sich assoziiert und Anwendungsprogrammierer können ihre eigenen Implementierungen auf einer pro-Transaktionsbasis bereitstellen."
 
 #. Tag: programlisting
 #: Chapter_03.xml:19
@@ -164,6 +167,9 @@
 "during the execution of a transactional application via the <classname>com."
 "arjuna.TxCore.Atomic.TxStats</classname> class:"
 msgstr ""
+"Standardmäßig bewahrt JBossTS keine Informationen zur Historie von Transaktionen. Wird jedoch die <literal>com.arjuna.ats.arjuna."
+"coordinator.enableStatistics</literal> Property-Variable auf YES gesetzt, so bewahrt der Transaktionsdienst Informationen zur Anzahl der erstellten Transaktionen und deren Ergebnissen auf. Diese Informationen können während der Ausführung einer transaktionalen Anwendung via der <classname>com."
+"arjuna.TxCore.Atomic.TxStats</classname>-Klasse abgerufen werden:"
 
 #. Tag: programlisting
 #: Chapter_03.xml:51
@@ -280,6 +286,11 @@
 "<classname>com.arjuna.ats.arjuna.LastResourceRecord</classname> and give "
 "your participant as the constructor parameter, as shown below:"
 msgstr ""
+"Um das LRCO zu nutzen muss Ihr Teilnehmer das "
+"<classname>com.arjuna.ats.arjuna.coordinator.OnePhase</classname>-Interface "
+"implementieren und durch <command>BasicAction</"
+"command>.add operation bei der Transaktion registriert sein; da diese Operation Instanzen von "
+"<classname>AbstractRecord</classname> erwartet, müssen Sie eine Instanz <classname>com.arjuna.ats.arjuna.LastResourceRecord</classname> erstellen und Ihren Teilnehmer als Konstruktorparameter angeben, wie unten gezeigt:"
 
 #. Tag: programlisting
 #: Chapter_03.xml:63
@@ -336,6 +347,8 @@
 "application programmers, and <emphasis>TxCore</emphasis> will guarantee "
 "their consistency."
 msgstr ""
+"Es gibt keine speziellen Konstrukte für das Verschachteln von Transaktionen: wird eine Aktion begonnen, während eine andere Action läuft, so wird sie automatisch verschachtelt. Dies erlaubt eine modulare Struktur für Anwendungen, wobei Objekte implementiert werden können, indem atomische Aktionen innerhalb ihrer Operationen verwendet werden, ohne dass der Anwendungsprogrammierer sich um die Anwendungen kümmern muss, die diese verwenden, d.h. ob die Anwendungen auch atomische Actions verwenden oder ob nicht. "
+"Daher sind Aktionen in manchen Anwendungen auf der obersten  Ebene, in anderen hingegen verschachtelt. Auf diese Weise geschriebene Objekte können sogar von Anwendungsprogrammierern geteilt werden und <emphasis>TxCore</emphasis> garantiert Konsistenz."
 
 #. Tag: para
 #: Chapter_03.xml:72
@@ -347,7 +360,7 @@
 "commits then the work it has performed will only be committed by the system "
 "if the top-level action commits; if the top-level action aborts then all of "
 "the work will be undone."
-msgstr ""
+msgstr "Wird eine verschachtelte Aktion abgebrochen, so wird alle ihre Arbeit rückgängig gemacht, obwohl striktes zwei Phasen Sperren bedeutet, dass alle Sperren, die möglicherweise vorhanden sind, erhalten bleiben bis die Aktion der höchsten Ebene festgeschrieben oder abgebrochen wird. Wird eine verschachtelte Aktion festgeschrieben, so wird die von ihr durchgeführte Arbeit vom System nur festgeschrieben, wenn die Aktion auf höchster Ebene festschreibt; wird die Aktion auf höchster Ebene abgebrochen, so wird alle ihre Arbeit rückgängig gemacht."
 
 #. Tag: para
 #: Chapter_03.xml:74
@@ -357,7 +370,7 @@
 "the outcome of the action within which it is nested. This is application "
 "dependant, and allows a programmer to structure atomic actions to contain "
 "faults, undo work, etc."
-msgstr ""
+msgstr "Das Festschreiben oder Abbrechen einer verschachtelten Aktion hat nicht automatisch Einfluss auf das Ergebnis der Aktion innerhalb derer sie verschachtelt ist. Dies hängt von der Anwendung ab und gestattet es dem Programmierer atomische Aktionen zu strukturieren, so dass diese Fehler enthalten, Arbeit rückgängig machen usw."
 
 #. Tag: title
 #: Chapter_03.xml:78
@@ -373,7 +386,7 @@
 "in a synchronous manner, i.e., all registered resources will be told to "
 "prepare in order by a single thread, and then they will be told to commit or "
 "rollback. This has several possible disadvantages:"
-msgstr ""
+msgstr "Standardmäßig führt JBossTS das Festschreibungsprotokoll einer Transaktion der höchsten Ebene auf synchrone Weise aus, d.h. alle registrierten Ressourcen wird mitgeteilt sich in der Anordnung eines einzelnen Threads vorzubereiten und anschließend entweder festgeschrieben oder zurückgesetzt zu werden. Dies hat mehrere mögliche Nachteile:"
 
 #. Tag: para
 #: Chapter_03.xml:83
@@ -384,7 +397,7 @@
 "if an “early” resource in the list of registered resource forces a rollback "
 "during prepare, possibly many prepare operations will have been made "
 "needlessly."
-msgstr ""
+msgstr "Im Falle vieler registrierter Ressourcen kann das \"Prepare Operating\" logisch parallel an jeder Ressource aufgerufen werden. Der Nachteil ist, dass eine \"frühe\" Ressource in der Liste registrierter Ressourcen ein Zurücksetzen während der Vorbereitung erzwingt, möglicherweise wurden viele \"Prepare Operations\" unnötigerweise gemacht."
 
 #. Tag: para
 #: Chapter_03.xml:84
@@ -393,7 +406,7 @@
 "In the case where heuristic reporting is not required by the application, "
 "the second phase of the commit protocol can be done asynchronously, since "
 "its success or failure is not important."
-msgstr ""
+msgstr "Im Falle wo heuristisches Reporting nicht durch die Anwendung benötigt wird, kann die zweite Phase des Festschreibungsprotokolls asynchron erfolgen, da Erfolg oder Fehlschlagen unwichtig sind."
 
 #. Tag: para
 #: Chapter_03.xml:87
@@ -409,6 +422,11 @@
 "second phase of the transaction if knowledge about heuristics outcomes is "
 "not required."
 msgstr ""
+"Daher liefert <emphasis>JBossTS</emphasis> Runtime-Optionen zur Aktivierung möglicher Threading-Optimierungen. Durch Einstellung der <literal>com.arjuna.ats."
+"arjuna.coordinator.asyncPrepare</literal>-Umgebungsvariable auf "
+"<literal>YES</literal>, während der Vorbereitungsphase wird ein separater Thread für jeden registrierten Teilnehmer innerhalb der Transaktion erstellt. Durch Einstellung von "
+"<literal>com.arjuna.ats.arjuna.coordinator.asyncCommit</literal> auf "
+"<literal>YES</literal>, wird ein separater Thread erstellt, um die zweite Phase der Transaktion zu vervollständigen, falls keine Kenntnisse über heuritische Ergebnisse notwendig sind."
 
 #. Tag: title
 #: Chapter_03.xml:93
@@ -427,7 +445,7 @@
 "behaves exactly like a normal top-level action, that is, its results are "
 "made permanent when it commits and will not be undone if any of the actions "
 "within which it was originally nested abort."
-msgstr ""
+msgstr "Zusätzlich zu normalen Top-Level und verschachtelten atomischen Aktionen unterstützt <emphasis>TxCore</emphasis> auch unabhängige Top-Level Aktionen, die dazu verwendet werden können strenge Serialisabilität auf kontrollierte Weise aufzulockern. Eine unabhängige Aktion der höchsten Ebene kann von überall aus innerhalb einer anderen atomischen Aktion ausgeführt werden und verhält sich genauso wie eine normale Aktion der höchsten Ebene, das heißt ihre Ergebnisse werden dauerhaft, wenn sie festgeschrieben wird und werden nicht rückgängig gemacht wenn jedwelche der Aktionen innerhalb derer sie ursprünglich verschachtelt wurde, abgebrochen werden."
 
 #. Tag: caption
 #: Chapter_03.xml:101
@@ -446,7 +464,7 @@
 "other actions within the structure. Because of the nature of independent top-"
 "level actions they should be used with caution and only in situations where "
 "their use has been carefully examined."
-msgstr ""
+msgstr "zeigt eine typische Verschachtelung atomischer Aktionen, wo Aktion B innerhalb Aktion A verschachtelt ist. Obwohl atomische Aktion C logisch innerhalb von Aktion B verschachtelt ist (ihre \"Begin\"-Operation wurde aufgerufen während B aktiv war) wird sie innerhalb der Struktur unabhängig von den anderen Aktionen festgeschrieben oder abgebrochen, weil es sich um eine unabhängige Aktion der obersten Ebene handelt. Aufgrund des Wesens unabhängiger Aktionen der obersten Ebene, sollten diese mit Vorsicht gehandhabt werden und nur in Situationen verwendet werden, die zuvor eingehend geprüft wurden."
 
 #. Tag: para
 #: Chapter_03.xml:106
@@ -455,7 +473,7 @@
 "Top-level actions can be used within an application by declaring and using "
 "instances of the class <classname>TopLevelTransaction</classname>. They are "
 "used in exactly the same way as other transactions."
-msgstr ""
+msgstr "Top-Level Aktionen können innerhalb einer Anwendung verwendet werden, indem Instanzen der Klasse <classname>TopLevelTransaction</classname> deklariert und verwendet werden. Sie werden auf genau diesselbe Weise wie andere Transaktionen verwendet."
 
 #. Tag: title
 #: Chapter_03.xml:111
@@ -477,6 +495,8 @@
 "violate the atomicity properties of the action being committed (aborted) and "
 "is thus discouraged."
 msgstr ""
+"Beim Schreiben der <command>save_state</command> und "
+"<command>restore_state</command>-Operationen sollte man Vorsicht walten lassen um sicherzustellen, dass keine atomischen Aktionen gestartet werden (entweder explizit in der Operation oder implizit durch Verwendung einer anderen Operation). Diese Einschränkung kommt aufgrund der Tatsache auf, dass <emphasis>TxCore</emphasis> <command>restore_state</command> als Teil seiner Festschreibungsbearbeitung aufrufen kann, was im Versuch resultiert eine atomische Aktion während der Festschreibungs- oder Abbruchphase einer anderen Aktion auszuführen. Dies könnte die Atomizität-Properties der Aktion verletzen, die gerade festgeschrieben (abgebrochen) wird und wird daher nicht empfohlen."
 
 #. Tag: title
 #: Chapter_03.xml:118
@@ -490,7 +510,7 @@
 msgid ""
 "If we consider the Array example given previously, the set and get "
 "operations could be implemented as shown below."
-msgstr ""
+msgstr "Wenn wir uns das zuvor gegebene Array-Beispiel ansehen, so würden die \"Set\" und \"Get\"-Operationen wie unten dargestellt implementiert."
 
 #. Tag: para
 #: Chapter_03.xml:122
@@ -594,7 +614,7 @@
 #: Chapter_03.xml:129
 #, no-c-format
 msgid "Garbage collecting objects"
-msgstr ""
+msgstr "Müll sammelnde Objekte"
 
 #. Tag: para
 #: Chapter_03.xml:131
@@ -608,7 +628,7 @@
 "object maintained by an application, <emphasis>TxCore</emphasis> will always "
 "retain its own references to ensure that the object is not garbage collected "
 "until after any transaction has terminated."
-msgstr ""
+msgstr "Java Objekte werden gelöscht, wenn der Müllsammler bestimmt, dass sie nicht länger benötigt werden. Das Löschen eines zum aktuellen Zeitpunkt unter Kontrolle einer Transaktion stehenden Objekts muss mit Vorsicht angegangen werden, da das Schicksal eines innerhalb einer Transaktion bearbeiteten Objekts ultimativ von der Transaktion bestimmt wird. Daher wird, unabhängig von Verweisen auf ein transaktionales und durch die Anwendung gewartetes Objekt <emphasis>TxCore</emphasis> stets seine eigenen Verweise behalten um sicherzustellen, dass das Objekt nicht als Müll gesammelt wird ehe die Transaktion nicht beendet wurde."
 
 #. Tag: title
 #: Chapter_03.xml:136