[jboss-svn-commits] JBL Code SVN: r25115 - labs/jbosstm/enterprise/tags/EAP_4_3_0/Transactions_Failure_Recovery_Guide/de-DE.

jboss-svn-commits at lists.jboss.org jboss-svn-commits at lists.jboss.org
Thu Feb 5 02:09:05 EST 2009


Author: hpeters
Date: 2009-02-05 02:09:05 -0500 (Thu, 05 Feb 2009)
New Revision: 25115

Modified:
   labs/jbosstm/enterprise/tags/EAP_4_3_0/Transactions_Failure_Recovery_Guide/de-DE/Architecture_of_the_Recovery_Manager.po
   labs/jbosstm/enterprise/tags/EAP_4_3_0/Transactions_Failure_Recovery_Guide/de-DE/How_JBossTS_managers_the_OTS_Recovery_Protocol.po
Log:
clearing fuzzies and proofreading

Modified: labs/jbosstm/enterprise/tags/EAP_4_3_0/Transactions_Failure_Recovery_Guide/de-DE/Architecture_of_the_Recovery_Manager.po
===================================================================
--- labs/jbosstm/enterprise/tags/EAP_4_3_0/Transactions_Failure_Recovery_Guide/de-DE/Architecture_of_the_Recovery_Manager.po	2009-02-05 06:44:31 UTC (rev 25114)
+++ labs/jbosstm/enterprise/tags/EAP_4_3_0/Transactions_Failure_Recovery_Guide/de-DE/Architecture_of_the_Recovery_Manager.po	2009-02-05 07:09:05 UTC (rev 25115)
@@ -8,7 +8,7 @@
 "Project-Id-Version: Architecture_of_the_Recovery_Manager\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2008-09-23 06:30+0000\n"
-"PO-Revision-Date: 2009-02-04 16:43+1000\n"
+"PO-Revision-Date: 2009-02-05 15:08+1000\n"
 "Last-Translator: Hedda Peters <hpeters at redhat.com>\n"
 "Language-Team: \n"
 "MIME-Version: 1.0\n"
@@ -1112,7 +1112,7 @@
 "During the prepare phase, it writes a simple message - <emphasis>I’m "
 "prepared</emphasis>- on the disk such The message is written in a well known "
 "file."
-msgstr "Während der Vorbereitungsphase schreibt er eine einfache Nachricht – <emphasis>I'm prepared</emphasis> – auf die Platte, wobei die Nachricht in eine \"well-known\"-Datei geschrieben wird."
+msgstr "Während der Vorbereitungsphase schreibt er eine einfache Nachricht – <emphasis>Ich bin vorbereitet</emphasis> – auf die Platte, wobei die Nachricht in eine \"well-known\" Datei geschrieben wird."
 
 #. Tag: para
 #: Architecture_of_the_Recovery_Manager.xml:374
@@ -1120,7 +1120,7 @@
 msgid ""
 "During the commit phase, it writes another message - <emphasis>I’m "
 "committed</emphasis>- in the same file used during prepare."
-msgstr "Während der Festschreibungsphase schreibt er eine weitere Nachricht – <emphasis>Ich bin festgeschrieben(???)</emphasis> – in dieselbe Datei wie schon während der Vorbereitungsphase."
+msgstr "Während der Festschreibungsphase schreibt er eine weitere Nachricht – <emphasis>Ich bin festgeschrieben</emphasis> – in dieselbe Datei wie schon während der Vorbereitungsphase."
 
 #. Tag: para
 #: Architecture_of_the_Recovery_Manager.xml:379
@@ -1128,16 +1128,15 @@
 msgid ""
 "If it receives an abort message, it removes from the disk the file used for "
 "prepare if any."
-msgstr "Falls er eine Abbruchnachricht empfängt, löscht er die bei der Vorbereitung verwendete Datei von der Platte, falls eine Datei existiert."
+msgstr "Falls er eine Abbruchnachricht empfängt, löscht er die bei der Vorbereitung verwendete Datei von der Platte, falls diese Datei existiert."
 
 #. Tag: para
 #: Architecture_of_the_Recovery_Manager.xml:384
 #, no-c-format
-#, fuzzy
 msgid ""
 "If a crash has been decided for the test, then it crashes during the commit "
 "phase – the file remains with the message <emphasis>I’m prepared</emphasis>."
-msgstr "Falls für den Test ein Crash vorgesehen wurde, dann crasht er während während der Festschreibungsphase – die Datei bleibt mit der <emphasis>Ich bin vorbereitet</emphasis>-Nachricht erhalten."
+msgstr "Falls für den Test ein Crash vorgesehen wurde, dann crasht er während während der Festschreibungsphase – die Datei verbleibt mit der <emphasis>Ich bin vorbereitet</emphasis>-Nachricht."
 
 #. Tag: para
 #: Architecture_of_the_Recovery_Manager.xml:389
@@ -1145,14 +1144,13 @@
 msgid ""
 "The main portion of the code illustrating such behavior is described "
 "hereafter."
-msgstr "Der Großteil des Codes, der diese Verhaltensweisen illustriert, wird nachfolgend beschrieben."
+msgstr "Der Hauptteil des Codes, der diese Verhaltensweisen illustriert, wird nachfolgend beschrieben."
 
 #. Tag: para
 #: Architecture_of_the_Recovery_Manager.xml:393
 #, no-c-format
-#, fuzzy
 msgid "The location of the file given in variable filename can be changed"
-msgstr "Der Speicherort der gegebenen Datei kann mit verschiedenen Dateinamen geändert werden."
+msgstr "Der Speicherort der Datei, der als Wert der Variablen <varname>filename</varname> spezifiziert ist, kann geändert werden."
 
 #. Tag: screen
 #: Architecture_of_the_Recovery_Manager.xml:397
@@ -1453,7 +1451,7 @@
 "Where &lt;i&gt; represent the new occurrence number that follows the last "
 "that already exists in the file. Once started, the Recovery Manager will "
 "automatically load the added Recovery module."
-msgstr "Wobei &lt;i&gt; die neue Vorgangsnummer ist, die auf die letzte bereits in der Datei existierende folgt. Sobald der Recovery-Manager gestartet ist, wird er automatisch das hinzugefügte Recovery-Modul laden."
+msgstr "Wobei &lt;i&gt; die neue Elementnummer ist, die auf die letzte bereits in der Datei existierende folgt. Sobald der Recovery-Manager gestartet ist, wird er automatisch das hinzugefügte Recovery-Modul laden."
 
 #. Tag: para
 #: Architecture_of_the_Recovery_Manager.xml:410
@@ -1478,7 +1476,7 @@
 "describe how the build a recovery module. In case of the OTS protocol, let’s "
 "consider how a recovery module that manages recovery of OTS resources can be "
 "configured."
-msgstr "Wie bereits erwähnt, stellt die oben gezeigte, einfache Anwendung nicht den vollständigen Prozess der Fehler-Recovery dar, sondern wurde nur gezeigt, um das Bauen eines Recovery-Moduls zu beschreiben. Im Fall des OTS-Protokolls, lassen Sie uns betrachten, wie ein Recovery-Modul konfiguriert werden kann, das die Wiederherstellung von OTS-Ressourcen steuert."
+msgstr "Wie bereits erwähnt, stellt die oben gezeigte, einfache Anwendung nicht den vollständigen Prozess der Recovery nach einem Fehlerfall dar, sondern wurde nur gezeigt, um das Bauen eines Recovery-Moduls zu beschreiben. Im Fall des OTS-Protokolls, lassen Sie uns betrachten, wie ein Recovery-Modul konfiguriert werden kann, das die Wiederherstellung von OTS-Ressourcen steuert."
 
 #. Tag: para
 #: Architecture_of_the_Recovery_Manager.xml:420
@@ -1491,7 +1489,7 @@
 "appropriate decision either by roll backing or committing. Asking the "
 "RecoveryCoordinator object to determine the status consists to invoke the "
 "replay_completion operation on the RecoveryCoordinator."
-msgstr "Um die Recovery im Fehlerfall zu steuern, haben die OTS-Spezifikationen ein Recovery-Protokoll definiert. Transaktionsteilnehmer in einem zweifelhaften Zustand können den Recovery-Koordinator nutzen, um den Zustand der Transaktion festzustellen. Entsprechend dieses Transaktionszustands können solche Teilnehmer die passende Entscheidung treffen, festzuschreiben oder zurückzusetzen. Die Anfrage an das Recovery-Koordinatorobjekt nach Feststellung des Zustands besteht in dem Aufruf der replay_completion-Operation auf dem Recovery-Koordinator."
+msgstr "Um die Recovery nach einem Fehlerfall zu steuern, haben die OTS-Spezifikationen ein Recovery-Protokoll definiert. Transaktionsteilnehmer in einem zweifelhaften Zustand können den Recovery-Koordinator nutzen, um den Zustand der Transaktion festzustellen. Abhängig von diesem Transaktionszustand können diese Teilnehmer die jeweils passende Entscheidung treffen, festzuschreiben oder zurückzusetzen. Die Anfrage an das Recovery-Koordinatorobjekt, den Zustand festzustellen, besteht in dem Aufruf der replay_completion-Operation auf dem Recovery-Koordinator."
 
 #. Tag: para
 #: Architecture_of_the_Recovery_Manager.xml:423
@@ -1503,7 +1501,7 @@
 "during the Resource registration process. Retrieving such "
 "RecoveryCoordinator per resource means that it has been stored in addition "
 "to other information describing the resource."
-msgstr "Für jede OTS-Ressource in zweifelhaftem Zustand ist bekannt, welcher Recovery-Koordinator aufzurufen ist, um den Zustand der Transaktion festzustellen, an der die Ressource beteiligt ist – es ist der Recovery-Koordinator, der zurückgekehrt ist während des Prozesses der Ressourcenregistrierung. Solch einen Recovery-Koordinator pro Ressource abzufragen bedeutet, dass er zusätzlich zu anderen Informationen gespeichert wurde, die die Ressource beschreiben."
+msgstr "Für jede OTS-Ressource in zweifelhaftem Zustand ist bekannt, welcher Recovery-Koordinator aufzurufen ist, um den Zustand der Transaktion festzustellen, an der die Ressource beteiligt ist – es ist der Recovery-Koordinator, der zurückgegeben wurde während des Prozesses der Ressourcenregistrierung. Solch einen RecoveryCoordinator pro Ressource abzufragen bedeutet, dass er zusätzlich zu anderen, die Ressource beschreibenden Informationen gespeichert wurde."
 
 #. Tag: para
 #: Architecture_of_the_Recovery_Manager.xml:426
@@ -1519,7 +1517,7 @@
 "operation that the status of the transaction. According to the returned "
 "status, an appropriate action would be taken (for instance, rollback the "
 "resource is the status is aborted or inactive)."
-msgstr "Ein Recovery-Modul zur Wiederherstellung von OTS-Ressourcen könnte die folgenden Verhaltensweisen besitzen. Wenn beim ersten Durchlauf vom Recovery-Manager dazu aufgefordert, ruft es von der Platte die Liste der Ressourcen ab, die sich in zweifelhaftem Zustand befinden. Wenn sich die im ersten Durchlauf abgerufenen Ressourcen während des zweiten Durchlaufs immer noch auf der Platte befinden, dann werden sie als Kandidaten für Recovery betrachtet. Aus diesem Grund fragt das Recovery-Modul für jeden Kandidaten dessen assoziierten Recovery-Koordinator ab und ruft die replay_completion-Operation auf entsprechend des Zustands der Transaktion. Abhängig vom zurückgegebenen Zustand wird eine angemessene Maßnahme durchgeführt (z. B. die Ressource zurücksetzen, wenn der Zustand abgebrochen oder inaktiv lautet)."
+msgstr "Ein Recovery-Modul zur Wiederherstellung von OTS-Ressourcen könnte die folgenden Verhaltensweisen besitzen. Wenn vom Recovery-Manager beim ersten Pass dazu aufgefordert, ruft es von der Platte die Liste der Ressourcen ab, die sich in zweifelhaftem Zustand befinden. Wenn sich die im ersten Pass abgerufenen Ressourcen während des zweiten Passes immer noch auf der Platte befinden, dann werden sie als Kandidaten für Recovery betrachtet. Aus diesem Grund fragt das Recovery-Modul für jeden Kandidaten dessen assoziierten RecoveryCoordinator ab und ruft die replay_completion-Operation auf entsprechend des Zustands der Transaktion. Abhängig vom zurückgegebenen Zustand werden angemessene Maßnahmen durchgeführt (z. B. die Ressource zurücksetzen, wenn der Zustand abgebrochen oder inaktiv lautet)."
 
 #. Tag: title
 #: Architecture_of_the_Recovery_Manager.xml:431
@@ -1536,7 +1534,7 @@
 "TransactionStatusManager objects. It maintains a table of "
 "TransactionStatusConnector obects each of which connects to a "
 "TransactionStatusManager object in an Application Process."
-msgstr "Das TransactionStatusConnectionManager-Objekt wird von den Recovery-Modulen verwendet, um den Zustand von Transaktionen abzufragen, und verhält sich wie ein Proxy für TransactionStatusManager-Objekte. Es bewahrt eine Tabelle mit TransactionStatusConnector-Objekten, von der jedes mit einem TransactionStatusManager-Objekt in einem Anwendungsprozess verbunden ist."
+msgstr "Das TransactionStatusConnectionManager-Objekt wird von den Recovery-Modulen verwendet, um den Zustand von Transaktionen abzufragen, und fungiert als Proxy für TransactionStatusManager-Objekte. Es bewahrt eine Tabelle mit TransactionStatusConnector-Objekten, von der jedes mit einem TransactionStatusManager-Objekt in einem Anwendungsprozess verbunden ist."
 
 #. Tag: para
 #: Architecture_of_the_Recovery_Manager.xml:435
@@ -1557,7 +1555,7 @@
 #: Architecture_of_the_Recovery_Manager.xml:440
 #, no-c-format
 msgid "Expired Scanner Thread"
-msgstr "Abgelaufener Scanner Thread"
+msgstr "Scanner Thread für abgelaufene Posten"
 
 #. Tag: para
 #: Architecture_of_the_Recovery_Manager.xml:441
@@ -1567,7 +1565,7 @@
 "ExpiryEntryMonitor is created which is used to remove long dead items from "
 "the ObjectStore. A number of scanner modules are dynamically loaded which "
 "remove long dead items for a particular type."
-msgstr "Wenn der Recovery-Manager einen Ablauf-Scanner-Thread initialisiert, wird ein ExpiryEntryMonitor erstellt, der verwendet wird zum Entfernen von schon länger toten Posten aus dem Objektspeicher. Eine Anzahl von Scanner-Modulen werden dynamisch geladen, welche tote Posten für einen bestimmten Typ entfernen."
+msgstr "Wenn der Recovery-Manager einen Scanner Thread für abgelaufene Posten initialisiert, wird ein ExpiryEntryMonitor erstellt, der verwendet wird zum Entfernen von schon länger toten Posten aus dem Objektspeicher. Eine Anzahl von Scanner-Modulen wird dynamisch geladen, die tote Posten eines bestimmten Typs entfernen."
 
 #. Tag: para
 #: Architecture_of_the_Recovery_Manager.xml:444
@@ -1575,7 +1573,7 @@
 msgid ""
 "Scanner modules are loaded at initialisation and are specified as properties "
 "beginning with"
-msgstr "Scanner-Module werden bei Initialisierung geladen und werden spezifiziert als Eigenschaften beginnend mit"
+msgstr "Scanner-Module werden bei Initialisierung geladen und spezifiziert als Eigenschaften beginnend mit"
 
 #. Tag: screen
 #: Architecture_of_the_Recovery_Manager.xml:447
@@ -1607,7 +1605,7 @@
 msgid ""
 "All scanners inherit the same behaviour from the java interface "
 "<interfacename>ExpiryScanner</interfacename> as illustrated in diagram below:"
-msgstr "Alle Scanner erben dieselben Verhaltensweisen von der Java-Schnittstelle <interfacename>ExpiryScanner</interfacename> wie im Diagramm unten dargestellt:"
+msgstr "Alle Scanner erben dieselben Verhaltensweisen von der Java-Schnittstelle <interfacename>ExpiryScanner</interfacename>, wie im Diagramm unten dargestellt:"
 
 #. Tag: para
 #: Architecture_of_the_Recovery_Manager.xml:460
@@ -1655,7 +1653,7 @@
 "Recovery Manager needs access to the transaction tables so that it can "
 "determine whether a transaction is still in progress, if so then recovery "
 "does not happen."
-msgstr "Dies repräsentiert das transaktionale Programm des Benutzers. Eine Tabelle für lokale Transaktionen (hash), die innerhalb der laufenden Anwendung gepflegt wird, verfolgt den aktuellen Zustand aller von dem Anwendungsprozess erstellten Transaktionen. Der Recovery-Manager benötigt Zugriff auf die Transaktionstabellen, damit er feststellen kann, ob eine Transaktion noch fortgeführt wird, in welchem Fall keine Recovery erfolgt."
+msgstr "Dies repräsentiert das transaktionale Programm des Benutzers. Eine Tabelle lokaler Transaktionen (hash), die innerhalb des laufenden Anwendungsprozesses gepflegt wird, verfolgt den aktuellen Zustand aller von dem Anwendungsprozess erstellten Transaktionen. Der Recovery-Manager benötigt Zugriff auf die Transaktionstabellen, damit er feststellen kann, ob eine Transaktion noch fortschreitet, in welchem Fall keine Recovery erfolgt."
 
 #. Tag: para
 #: Architecture_of_the_Recovery_Manager.xml:476
@@ -1696,7 +1694,7 @@
 "for communication between the RecoveryManager and TransactionStatusManager. "
 "Any free port is used by the TransactionStatusManager by default, however "
 "the port can be fixed with the property:"
-msgstr "Dieses Objekt fungiert als eine Schnittstelle für den Recovery-Manager, um den Zustand von Transaktionen von laufenden HPTS-Anwendungsprozessen zu erhalten. Ein TransactionStatusManager wird erstellt pro Anwendungsprozess durch die Klasse com.arjuna.ats.arjuna.coordinator.InitAction. Derzeit wird eine TCP-Verbindung verwendet für die Kommunikation zwischen dem Recovery-Manager und dem TransactionStatusManager. Standardmäßig wird ein beliebiger freier Port vom TransactionStatusManager benutzt, der Port kann jedoch auch festgelegt werden mithilfe der Eigenschaft:"
+msgstr "Dieses Objekt fungiert als eine Schnittstelle für den Recovery-Manager, um den Zustand von Transaktionen von laufenden HPTS-Anwendungsprozessen zu erhalten. Pro Anwendungsprozess wird ein TransactionStatusManager erstellt durch die Klasse com.arjuna.ats.arjuna.coordinator.InitAction. Derzeit wird eine TCP-Verbindung verwendet für die Kommunikation zwischen dem Recovery-Manager und dem TransactionStatusManager. Standardmäßig wird ein beliebiger, freier Port vom TransactionStatusManager benutzt, der Port kann jedoch auch festgelegt werden mithilfe der Eigenschaft:"
 
 #. Tag: screen
 #: Architecture_of_the_Recovery_Manager.xml:488
@@ -1716,7 +1714,7 @@
 "accepts a transaction Uid and a transaction type (if available) from a "
 "TransactionStatusConnector, the transaction status is obtained from the "
 "local thransaction table and returned back to the TransactionStatusConnector."
-msgstr "Bei Erstellung erhält der TransactionStatusManager einen Port, den er beim Host im Objektspeicher ablegt als ein TransactionStatusManagerItem. Ein Listener Thread wird gestartet, der auf eine Verbindungsanfrage von einem TransactionStatusConnector wartet. Wenn eine Verbindung hergestellt wird, wird ein Verbindungs-Thread erstellt, der einen Dienst (AtomicActionStatusService) ausführt, welcher eine Transaktions-Uid und einen Transaktionstyp (falls verfügbar) akzeptiert, der Transaktionszustand wird von der Tabelle für lokale Transaktionen bezogen, und zurückgegeben an den TransactionStatusConnector."
+msgstr "Bei Erstellung erhält der TransactionStatusManager einen Port, den er beim Host im Objektspeicher ablegt als ein TransactionStatusManagerItem. Ein Listener Thread wird gestartet, der auf eine Verbindungsanfrage von einem TransactionStatusConnector wartet. Wenn eine Verbindung hergestellt wird, wird ein Verbindungs-Thread erstellt, der einen Dienst (AtomicActionStatusService) ausführt, welcher eine Transaktions-Uid und einen Transaktionstyp (falls verfügbar) akzeptiert. Der Transaktionszustand wird von der Tabelle für lokale Transaktionen bezogen, und zurückgegeben an den TransactionStatusConnector."
 
 #. Tag: title
 #: Architecture_of_the_Recovery_Manager.xml:494
@@ -1731,15 +1729,16 @@
 "All objects are stored in a file path which is equivalent to their class "
 "inheritance. Thus AtomicAction transactions are stored in file path ../"
 "StateManager/BasicAction/AtomicAction."
-msgstr "Alle Objekte sind in einem Dateipfad abgelegt, der äquivalent ist zu ihren geerbten Klassen. Demnach werden AtomicAction-Transaktionen im Dateipfad ../StateManager/BasicAction/AtomicAction abgelegt."
+msgstr "Alle Objekte werden in einem Dateipfad abgelegt, der ihren geerbten Klassen entspricht. Demnach werden AtomicAction-Transaktionen im Dateipfad ../StateManager/BasicAction/AtomicAction abgelegt."
 
 #. Tag: para
 #: Architecture_of_the_Recovery_Manager.xml:498
 #, no-c-format
+#, fuzzy
 msgid ""
 "All objects are identified by a unique identifier Uid. One of the values of "
 "which is a process id in which the object was created. The Recovery Manager "
 "uses the process id to locate transaction status manager items when "
 "contacting the originator application process for the transaction status."
-msgstr "Alle Objekte werden durch eine eindeutige Identifier-Uid identifiziert. Einer ihrer Werte ist eine Prozess-id, in der das Objekt erstellt wurde. Der Recover-Manager verwendet die Prozess-id, um Posten des Transaktionsstatusmanagers zu finden, während er den originären Anwendungsprozess für den Transaktionszustand kontaktiert."
+msgstr "Alle Objekte werden mithilfe einer eindeutigen Identifier-Uid identifiziert. Einer ihrer Werte ist die Prozess-ID, in der das Objekt erstellt wurde. Der Recovery-Manager verwendet die Prozess-ID, um Elemente des Transaktionszustandmanagers zu finden, wenn er den originären Anwendungsprozess für den Transaktionszustand kontaktiert."
 

Modified: labs/jbosstm/enterprise/tags/EAP_4_3_0/Transactions_Failure_Recovery_Guide/de-DE/How_JBossTS_managers_the_OTS_Recovery_Protocol.po
===================================================================
--- labs/jbosstm/enterprise/tags/EAP_4_3_0/Transactions_Failure_Recovery_Guide/de-DE/How_JBossTS_managers_the_OTS_Recovery_Protocol.po	2009-02-05 06:44:31 UTC (rev 25114)
+++ labs/jbosstm/enterprise/tags/EAP_4_3_0/Transactions_Failure_Recovery_Guide/de-DE/How_JBossTS_managers_the_OTS_Recovery_Protocol.po	2009-02-05 07:09:05 UTC (rev 25115)
@@ -8,7 +8,7 @@
 "Project-Id-Version: How_JBossTS_managers_the_OTS_Recovery_Protocol\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2008-09-23 06:30+0000\n"
-"PO-Revision-Date: 2009-02-03 15:11+1000\n"
+"PO-Revision-Date: 2009-02-05 17:06+1000\n"
 "Last-Translator: Hedda Peters <hpeters at redhat.com>\n"
 "Language-Team: \n"
 "MIME-Version: 1.0\n"
@@ -37,7 +37,7 @@
 "the RecoveryCoordinator to determine the status of the transaction. "
 "According to that transaction status, those participants can take "
 "appropriate decision either by roll backing or committing."
-msgstr "Um die Recovery im Fehlerfall zu steuern, haben die OTS-Spezifikationen ein Recovery-Protokoll definiert. Transaktionsteilnehmer in einem zweifelhaften Zustand können den Recovery-Koordinator nutzen, um den Zustand der Transaktion festzustellen. Entsprechend dieses Transaktionszustands können solche Teilnehmer die passende Entscheidung treffen, festzuschreiben oder zurückzusetzen."
+msgstr "Um die Recovery nach einem Fehlerfall zu steuern, haben die OTS-Spezifikationen ein Recovery-Protokoll definiert. Transaktionsteilnehmer in einem zweifelhaften Zustand können den RecoveryCoordinator nutzen, um den Zustand der Transaktion festzustellen. Entsprechend dieses Transaktionszustands können diese Teilnehmer die passende Entscheidung treffen, festzuschreiben oder zurückzusetzen."
 
 #. Tag: para
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:14
@@ -48,13 +48,13 @@
 "is implicitly associated with a single Resource, can be used to drive the "
 "Resource through recovery procedures in the event of a failure occurring "
 "during the transaction."
-msgstr "Eine Referenz zu einem Recovery-Koordinator wird zurückgegeben infolge es erfolgreichen Aufrufs von register_resource auf dem Transaktions-Koordinator. Dieses Objekt, welches implizit mit einer einzelnen Ressource assoziiert ist, kann verwendet werden zum Steuern der Ressource durch die Recovery-Prozedur, falls während der Transaktion ein Fehler auftrat."
+msgstr "Eine Referenz zu einem RecoveryCoordinator wird zurückgegeben als Ergebnis des erfolgreichen Aufrufs von register_resource auf dem Transaktions-Koordinator. Dieses Objekt, welches implizit mit einer einzelnen Ressource assoziiert ist, kann dazu verwendet werden, die Ressource durch die Recovery-Prozedur zu schicken, falls während der Transaktion ein Fehler auftritt."
 
 #. Tag: caption
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:21
 #, no-c-format
 msgid "Resource and RecoveryCoordinator relationship."
-msgstr "Ressource- und RecoveryCoordinator-Beziehung"
+msgstr "Beziehung zwischen Ressource und RecoveryCoordinator."
 
 #. Tag: title
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:26
@@ -75,7 +75,7 @@
 "enhances performance by avoiding the creation of servants but it relies on a "
 "default RecoveryCoordinator object with it’s associated default servant to "
 "manage all replay_completion invocations."
-msgstr "Bei jeder Registrierung einer Ressource wird erwartet, dass eines RecoveryCoordinator-Objekts erstellt und an die Anwendung zurückgegeben wird, die die register_resource-Operation aufgerufen hat. Hinter jedem CORBA-Objekt sollte eine Objektimplementierung oder ein Servant-Objekt, in POA-Begriffen (???), geben, das Operationen ausführt, die auf einem RecoveryCoordinator-Objekt gemacht werden. Anstatt ein RecoveryCoordinator-Objekt mit seinen assoziierten Servants auf jeder register_resource zu erstellen, verbessert JBossTS die Leistung, indem die Erstellung von Servants vermieden wird, und stattdessen ein Standard-RecoveryCoordinator-Objekt mit dessen assoziierten Standard-Servant verwendet wird, um alle replay_completion-Aufrufe zu steuern."
+msgstr "Bei jeder Registrierung einer Ressource wird erwartet, dass ein RecoveryCoordinator-Objekts erstellt und an die Anwendung zurückgegeben wird, welche die register_resource-Operation aufgerufen hat. Hinter jedem CORBA-Objekt sollte eine Objektimplementierung oder ein Servant-Objekt stehen, in POA-Begriffen, das Operationen ausführt, die auf einem RecoveryCoordinator-Objekt erfolgen. Anstatt ein RecoveryCoordinator-Objekt mit seinem assoziierten Servant auf jeder register_resource zu erstellen, verbessert JBossTS die Performanz, indem es die Erstellung von Servants vermeidet und stattdessen auf ein Standard-RecoveryCoordinator-Objekt mit seinem assoziierten Standard-Servant baut, um alle replay_completion-Aufrufe zu steuern."
 
 #. Tag: para
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:30
@@ -84,13 +84,13 @@
 "In the next sections we first give an overview of the Portable Object "
 "Adapter architecture, then we describe how this architecture is used to "
 "provide RecoveryCoordinator creation with optimization as explained above."
-msgstr "In den nächsten Abschnitten bieten wir zunächst einen Überblick über die \"Portable Object Adapter\"-Architektur, und beschreiben anschließend, wie diese Architektur benutzt werden kann zum Liefern der RecoveryCoordinator-Erstellung mit Optimierung wie oben ausgeführt."
+msgstr "In den nächsten Abschnitten bieten wir zunächst einen Überblick über die \"Portable Object Adapter\"-Architektur, und beschreiben anschließend, wie diese Architektur benutzt werden kann zur Erstellung eines RecoveryCoordinators mit der oben erläuterten Optimierung."
 
 #. Tag: title
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:34
 #, no-c-format
 msgid "Understanding POA"
-msgstr "POA verstehen"
+msgstr "Der POA"
 
 #. Tag: para
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:35
@@ -100,13 +100,13 @@
 "a client request and identifies the object that satisfies the client "
 "request. The Object is then invoked and the response is returned to the "
 "client."
-msgstr "Im Prinzip ist der Portable Object Adapter, oder POA, ein Objekt, das eine Client-Anfrage abfängt und dasjenige Objekt identifiziert, welches die Client-Anfrage beantwortet. Das Objekt wird dann aufgerufen und die Antwort an den Client zurückgegeben."
+msgstr "Im Wesentlichen ist der Portable Object Adapter, oder POA, ein Objekt, das eine Client-Anfrage abfängt und dasjenige Objekt identifiziert, welches die Client-Anfrage beantwortet. Das Objekt wird dann aufgerufen und die Antwort an den Client zurückgegeben."
 
 #. Tag: caption
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:43
 #, no-c-format
 msgid "Overview of the POA."
-msgstr "Überblick über den POA"
+msgstr "Überblick über den POA."
 
 #. Tag: para
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:45
@@ -124,7 +124,7 @@
 "the objects, which are identified by Object Ids, a POA also provides a name "
 "space for POAs. A POA is created as a child of an existing POA, which forms "
 "a hierarchy starting with the root POA."
-msgstr "Das Objekt, das die Client-Anfrage ausführt, wird als ein Servant bezeichnet, welcher die Implementierung des vom Client angefragten CORBA-Objekts liefert. Ein Servant liefert die Implementierungen für eine oder mehrere CORBA-Objektreferenzen. Um einen Servant abzufragen, bewahrt jeder POA eine Active Object Map, die alle Objekte enthält, die in dem POA aktiviert wurden zu einem Servant. Für alle eingehende Anfragen sucht der POA die Objektreferenz in der Active Object Map und versucht, den verantwortlichen Servant zu finden. Falls keiner gefunden wird, wird die Anfrage entweder an einen Standard-Servant delegiert, oder ein Servant-Manager wird aufgerufen, um einen passenden Servant zu aktivieren bzw. zu finden. Zusätzlich zum Namensraum für die Objekte, welche durch Objekt-Ids identifiziert werden, stellt der POA auch einen Namensraum bereit für POAs. Ein POA wird erstellt als ein Child eines vorhandenen POAs, wodurch eine Hierarchie gebildet wird ausgehend !
 vom Root-POA."
+msgstr "Das Objekt, das die Client-Anfrage ausführt, wird als ein Servant bezeichnet, welcher die Implementierung des vom Client angefragten CORBA-Objekts bereitstellt. Ein Servant liefert die Implementierung für eine oder mehrere CORBA-Objektreferenzen. Um einen Servant abzufragen, pflegt jeder POA eine \"Active Object Map\", die alle Objekte enthält, die in dem POA aktiviert wurden zu einem Servant. Für alle eingehende Anfragen sucht der POA die Objektreferenz in der Active Object Map und versucht, den verantwortlichen Servant zu finden. Falls keiner gefunden wird, wird die Anfrage entweder an einen Standard-Servant delegiert, oder ein Servant-Manager wird aufgerufen, um einen passenden Servant zu aktivieren bzw. zu finden. Zusätzlich zum Namensraum für die Objekte, welche durch Objekt-IDs identifiziert werden, stellt der POA auch einen Namensraum bereit für POAs. Ein POA wird als ein Child eines vorhandenen POAs erstellt, wodurch eine Hierarchie ausgehend vom Root!
 -POA gebildet wird."
 
 #. Tag: para
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:48
@@ -134,7 +134,7 @@
 "creating a new POA, the default set of policies can be used or different "
 "values can be assigned that suit the application requirements. The POA "
 "specification defines:"
-msgstr "Jeder POA hat eine Reihe von Richtlinien, die seine Charakteristiken definieren. Beim Erstellen eines neuen POAs kann das standardmäßige Set von Richtlinien verwendet werden, oder es können andere Werte zugewiesen werden, abgestimmt auf die Anforderungen der Anwendung. Die POA-Spezifikationen definieren:"
+msgstr "Jeder POA hat ein Set von Richtlinien, die seine Charakteristiken definieren. Beim Erstellen eines neuen POAs kann das standardmäßige Set von Richtlinien verwendet werden, oder es können andere Werte zugewiesen werden, abgestimmt auf die Anforderungen der Anwendung. Die POA-Spezifikationen definieren:"
 
 #. Tag: para
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:53
@@ -142,7 +142,7 @@
 msgid ""
 "<emphasis>Thread policy:</emphasis> Specifies the threading model to be used "
 "by the POA. Possible values are:"
-msgstr "<emphasis>Thread policy:</emphasis> Spezifiziert das Threading-Modell, das vom POA verwendet wird. Mögliche Werte sind:"
+msgstr "<emphasis>Thread-Richtlinie</emphasis> (Thread policy): Spezifiziert das Threading-Modell, das vom POA verwendet werden soll. Mögliche Werte sind:"
 
 #. Tag: para
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:58
@@ -164,7 +164,7 @@
 msgid ""
 "<emphasis>Lifespan policy:</emphasis> Specifies the lifespan of the objects "
 "implemented in the POA. The lifespan policy can have the following values:"
-msgstr "<emphasis>Lifespan policy:</emphasis> Spezifiziert die Lebenszeit der im POA implementierten Objekte. Die Richtline zur Lebenszeit kann folgende Werte annehmen:"
+msgstr "<emphasis>Richtlinie zur Lebenszeit</emphasis> (Lifespan policy): Spezifiziert die Lebenszeit der im POA implementierten Objekte. Die Richtline zur Lebenszeit kann folgende Werte annehmen:"
 
 #. Tag: para
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:75
@@ -174,7 +174,7 @@
 "process in which they are first created. Once the POA is deactivated, an "
 "OBJECT_NOT_EXIST exception occurs when attempting to use any object "
 "references generated by the POA."
-msgstr "TRANSIENT (Standard): Diese im POA implementierten Objekte können nicht länger leben als der Prozess, in dem sie zuerst erstellt wurden. Sobald der POA deaktiviert ist, wird eine OBJECT_NOT_EXIST-Ausnahme ausgegeben, wenn versucht wird, jegliche vom POA generierte Objektreferenzen zu verwenden."
+msgstr "TRANSIENT (Standard): Im POA implementierte Objekte können nicht länger leben als der Prozess, in dem sie erstellt wurden. Sobald der POA deaktiviert ist, wird eine OBJECT_NOT_EXIST-Ausnahme ausgegeben, wenn versucht wird, jegliche vom POA generierte Objektreferenz zu verwenden."
 
 #. Tag: para
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:80
@@ -182,7 +182,7 @@
 msgid ""
 "PERSISTENT Objects implemented in the POA can outlive the process in which "
 "they are first created."
-msgstr "PERSISTENT: Diese im POA implementierten Objekte können länger leben als der der Prozess, in dem sie zuerst erstellt wurden."
+msgstr "PERSISTENT: Im POA implementierte Objekte können länger leben als der der Prozess, in dem sie erstellt wurden."
 
 #. Tag: para
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:87
@@ -191,7 +191,7 @@
 "Object ID Uniqueness policy: Allows a single servant to be shared by many "
 "abstract objects. The Object ID Uniqueness policy can have the following "
 "values:"
-msgstr "Richtlinie zur Eindeutigkeit der Objekt-ID: Erlaubt die gemeinsame Verwendung eines einzelnen Servants durch viele abstrakte Objekte. Die Richtlinie zur Eindeutigkeit der Objekt-ID kann folgende Werte haben:"
+msgstr "Richtlinie zur Eindeutigkeit der Objekt-ID (Object ID Uniqueness policy): Erlaubt die gemeinsame Verwendung eines einzelnen Servants durch viele abstrakte Objekte. Die Richtlinie zur Eindeutigkeit der Objekt-ID kann folgende Werte haben:"
 
 #. Tag: para
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:92
@@ -205,7 +205,7 @@
 msgid ""
 "MULTIPLE_ID: Activated servants can have one or more Object IDs. The Object "
 "ID must be determined within the method being invoked at run time."
-msgstr "MULTIPLE_ID: Aktivierte Servants können eine oder mehr Objekt-IDs besitzen. Die Objekt-ID muss festgelegt werden innerhalb der Methode, die zur Laufzeit aufgerufen wird."
+msgstr "MULTIPLE_ID: Aktivierte Servants können eine oder mehrere Objekt-IDs besitzen. Die Objekt-ID muss bestimmt werden in der Methode, die zur Laufzeit aufgerufen wird."
 
 #. Tag: para
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:104
@@ -214,7 +214,7 @@
 "ID Assignment policy: Specifies whether object IDs are generated by server "
 "applications or by the POA. The ID Assignment policy can have the following "
 "values:"
-msgstr "Richtlinie zur ID-Zuweisung: Spezifiziert, ob Objekt-IDs von Serveranwendungen oder vom POA generiert werden. Die Richtlinie zur ID-Zuweisung kann folgende Werte annehmen:"
+msgstr "Richtlinie zur ID-Zuweisung (ID Assignment policy): Spezifiziert, ob Objekt-IDs von Serveranwendungen oder vom POA generiert werden. Die Richtlinie zur ID-Zuweisung kann folgende Werte annehmen:"
 
 #. Tag: para
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:109
@@ -235,7 +235,7 @@
 "Servant Retention policy: Specifies whether the POA retains active servants "
 "in the Active Object Map. The Servant Retention policy can have the "
 "following values:"
-msgstr "Richtlinie zur Erhaltung von Servants: Spezifiziert, ob der POA aktive Servants in der Active Object Map behält. Die Richtlinie zur Erhaltung von Servants kann folgende Werte haben:"
+msgstr "Richtlinie zur Erhaltung von Servants (Servant Retention policy): Spezifiziert, ob der POA aktive Servants in der Active Object Map bewahrt. Die Richtlinie zur Erhaltung von Servants kann folgende Werte haben:"
 
 #. Tag: para
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:126
@@ -244,7 +244,7 @@
 "RETAIN (Default) The POA tracks object activations in the Active Object Map. "
 "RETAIN is usually used with ServantActivators or explicit activation methods "
 "on POA."
-msgstr "RETAIN (Standard): Der POA verfolgt die Aktivierung von Objekten in der Acitve Object Map. RETAIN wird in der Regel angewendet mit ServantActivators oder expliziten Aktivierungsmethoden auf POA."
+msgstr "RETAIN (Standard): Der POA verfolgt die Aktivierung von Objekten in der Acitve Object Map nach. RETAIN wird in der Regel angewendet mit ServantActivators oder expliziten Aktivierungsmethoden auf POA."
 
 #. Tag: para
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:131
@@ -258,7 +258,7 @@
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:138
 #, no-c-format
 msgid "Request Processing policy: Specifies how requests are processed by the POA."
-msgstr "Richtlinie zur Anfrageverarbeitung: Spezifiziert, wie Anfragen vom POA verarbeitet werden."
+msgstr "Richtlinie zur Anfrageverarbeitung (Request Processing policy): Spezifiziert die Art, wie Anfragen vom POA verarbeitet werden."
 
 #. Tag: para
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:143
@@ -267,7 +267,7 @@
 "USE_ACTIVE_OBJECT_MAP (Default): If the Object ID is not listed in the "
 "Active Object Map, an OBJECT_NOT _EXIST exception is returned. The POA must "
 "also use the RETAIN policy with this value."
-msgstr "USE_ACTIVE_OBJECT_MAP (Standard): Falls die Objekt-ID nicht in der Active Object Map verzeichnet ist, wird eine OBJECT_NOT_EXIST-Ausnahme zurückgegeben. Der POA muss auch die RETAIN-Richtlinie mit diesem Wert verwenden."
+msgstr "USE_ACTIVE_OBJECT_MAP (Standard): Falls die Objekt-ID nicht in der Active Object Map verzeichnet ist, wird eine OBJECT_NOT_EXIST-Ausnahme zurückgegeben. Der POA muss mit diesem Wert auch die RETAIN-Richtlinie verwenden."
 
 #. Tag: para
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:148
@@ -277,7 +277,7 @@
 "or the NON_RETAIN policy is set, the request is dispatched to the default "
 "servant. If no default servant has been registered, an OBJ_ADAPTER exception "
 "is returned. The POA must also use the MULTIPLE_ID policy with this value."
-msgstr "USE_DEFAULT_SERVANT: Falls die Objekt-ID nicht in der Active Object Map verzeichnet ist, oder die NON_RETAIN-Richtlinie gesetzt ist, wird die Anfrage an den Standard-Servant gegeben. Wenn kein Standard-Servant registriert wurde, wird eine OBJ_ADAPTER-Ausnahme zurückgegeben. Der POA muss auch die MULTIPLE_ID-Richtlinie mit diesem Wert verwenden."
+msgstr "USE_DEFAULT_SERVANT: Falls die Objekt-ID nicht in der Active Object Map verzeichnet ist oder die NON_RETAIN-Richtlinie gesetzt ist, wird die Anfrage an den Standard-Servant gegeben. Wenn kein Standard-Servant registriert wurde, wird eine OBJ_ADAPTER-Ausnahme zurückgegeben. Der POA muss mit diesem Wert auch die MULTIPLE_ID-Richtlinie verwenden."
 
 #. Tag: para
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:153
@@ -286,10 +286,7 @@
 "USE_SERVANT_MANAGER: If the Object ID is not listed in the Active Object Map "
 "or the NON_RETAIN policy is set, the servant manager is used to obtain a "
 "servant."
-msgstr ""
-"USE_SERVANT_MANAGER: If the Object ID is not listed in the Active Object Map "
-"or the NON_RETAIN policy is set, the servant manager is used to obtain a "
-"servant."
+msgstr "USE_SERVANT_MANAGER: Falls die Objekt-ID nicht in der Active Object Map verzeichnet ist oder die NON_RETAIN-Richtlinie gesetzt ist, wird mittels des Servant-Managers ein Servant bezogen."
 
 #. Tag: para
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:160
@@ -298,7 +295,7 @@
 "Implicit Activation policy: Specifies whether the POA supports implicit "
 "activation of servants. The Implicit Activation policy can have the "
 "following values:"
-msgstr "Richtlinie zur impliziten Aktivierung: Spezifiziert, ob der POA implizite Aktivierung von Servants unterstützt. Die Richtlinie zur impliziten Aktivierung kann folgende Werte haben:"
+msgstr "Richtlinie zur impliziten Aktivierung (Implicit Activation policy): Spezifiziert, ob der POA implizite Aktivierung von Servants unterstützt. Die Richtlinie zur impliziten Aktivierung kann folgende Werte haben:"
 
 #. Tag: para
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:165
@@ -309,7 +306,7 @@
 "<methodname>org.omg.PortableServer.POA.servant_to_reference()</methodname> "
 "or by invoking <methodname>_this()</methodname> on the servant. The POA must "
 "also use the SYSTEM_ID and RETAIN policies with this value."
-msgstr "IMPLICIT_ACTIVATION: Der POA unterstützt implizite Aktivierung von Servants. Servants können aktiviert werden, indem sie in eine Objektreferenz konvertiert werden mit <methodname>org.omg.PortableServer.POA.servant_to_reference()</methodname>, oder durch Aufruf von <methodname>_this()</methodname> auf dem Servant. Der POA muss auch die SYSTEM_ID- und RETAIN-Richtlinien mit diesem Wert verwenden."
+msgstr "IMPLICIT_ACTIVATION: Der POA unterstützt implizite Aktivierung von Servants. Servants können aktiviert werden, indem sie in eine Objektreferenz konvertiert werden mit <methodname>org.omg.PortableServer.POA.servant_to_reference()</methodname>, oder durch Aufruf von <methodname>_this()</methodname> auf dem Servant. Der POA muss mit diesem Wert auch die SYSTEM_ID- und RETAIN-Richtlinien verwenden."
 
 #. Tag: para
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:170
@@ -336,7 +333,7 @@
 "separate process from the client and server applications. The next section "
 "explains how the indirection to a default Servant located on a separate "
 "process is provided for ORBIX and for JacORB."
-msgstr "Um replay_completion-Aufrufe umzuleiten an Standard-Servants, müssen wir anscheinend einen POA erstellen mit zugewiesener Richtlinie zur Anfrageverarbeitung, deren Wert auf USE_DEFAULT_SERVANT gesetzt ist. Um jedoch diesen Standard-Servant zu erreichen, sollten wir zunächst den POA erreichen, der die Anfrage an den Standard-Servant weiterleitet. Tatsächlich verwendet der ORB eine Reihe von Informationen, um einen POA abzufragen; diese Informationen sind in der vom Client verwendeten Objektreferenz enthalten. Unter diesen Informationen sind die IP-Adresse und die Port-Nummer, wo sich der Server befindet, und auch der POA-Name. JBossJTA liefert einen Servant pro Maschine, um replay_completion-Aufrufe auszuführen. Dieser Servant befindet sich im Recovery-Managerprozess. Der Recovery-Managerprozess ist ein separater Prozess von den Client- und Serveranwendungen. Der nächste Abschnitt erläutert, wie die Umleitung an einen Standard-Servant, der auf einem separaten P!
 rozess liegt, für ORBIX und für JacORB bereitgestellt wird"
+msgstr "Um replay_completion-Aufrufe umzuleiten an Standard-Servants, müssen wir anscheinend einen POA erstellen mit zugewiesener Richtlinie zur Anfrageverarbeitung, deren Wert auf USE_DEFAULT_SERVANT gesetzt ist. Um jedoch den Standard-Servant zu erreichen, müssen wir zunächst den POA erreichen, der die Anfrage an den Standard-Servant weiterleitet. Tatsächlich nutzt der ORB eine Reihe von Informationen, um einen POA abzufragen; diese Informationen sind in der vom Client verwendeten Objektreferenz enthalten. Unter diesen Informationen ist die IP-Adresse und die Port-Nummer, wo sich der Server befindet, sowie der POA-Name. JBossJTA stellt pro Maschine einen Servant bereit, um replay_completion-Aufrufe auszuführen. Dieser Servant befindet sich im Recovery-Managerprozess. Der Recovery-Managerprozess ist ein von den Client- und Serveranwendungen separater Prozess. Der nächste Abschnitt erläutert, wie die Umleitung an einen Standard-Servant, der auf einem separaten Prozes!
 s liegt, für ORBIX und für JacORB bereitgestellt wird."
 
 #. Tag: title
 #: How_JBossTS_managers_the_OTS_Recovery_Protocol.xml:182




More information about the jboss-svn-commits mailing list