[jboss-cvs] JBossAS SVN: r87608 - projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE.

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

Author: hpeters
Date: 2009-04-21 03:12:18 -0400 (Tue, 21 Apr 2009)
New Revision: 87608

Modified:
   projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Clustered_Singleton_Services.po
   projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_EJBs.po
   projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Entity_EJBs.po
   projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_HTTP.po
   projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JBoss_Cache_JGroups.po
   projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JMS.po
Log:
proofreading in progress

Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Clustered_Singleton_Services.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Clustered_Singleton_Services.po	2009-04-21 07:06:05 UTC (rev 87607)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Clustered_Singleton_Services.po	2009-04-21 07:12:18 UTC (rev 87608)
@@ -9,7 +9,7 @@
 "Project-Id-Version: Clustering_Guide_Clustered_Singleton_Services\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2009-01-20 02:37+0000\n"
-"PO-Revision-Date: 2009-03-02 16:02+1000\n"
+"PO-Revision-Date: 2009-04-21 15:16+1000\n"
 "Last-Translator: Hedda Peters <hpeters at redhat.com>\n"
 "Language-Team: \n"
 "MIME-Version: 1.0\n"
@@ -55,7 +55,7 @@
 "different nodes in the cluster start and stop; based on those notifications "
 "each node in the cluster can independently (but consistently) determine if "
 "it is now the master node and needs to begin providing a service."
-msgstr "Der JBoss Applikationsserver (AS) bietet Unterstützung für eine Reihe von Strategien, die Ihnen beim Deployment von geclusterten Singleton-Diensten behilflich sein sollen. In diesem Abschnitt werden wir die verschiedenen Strategien behandeln. Alle diese Strategien bauen auf dem in der Einführung beschriebenen HAPartition-Dienst auf. Sie sind darauf angewiesen, dass <literal>HAPartition</literal> Benachrichtigungen ausgibt, wenn verschiedene Nodes dem Cluster beitreten oder daraus austreten; basierend auf diesen Benachrichtigungen kann jeder Node im Cluster unabhängig (aber widerspruchsfrei) feststellen, ob er nun der Master Node ist und jetzt einen Dienst bereitstellen muss."
+msgstr "Der JBoss Application Server (AS) bietet Unterstützung für eine Reihe von Strategien, die Ihnen beim Deployment von geclusterten Singleton-Diensten behilflich sein sollen. In diesem Abschnitt werden wir die verschiedenen Strategien behandeln. Alle diese Strategien bauen auf dem in der Einführung beschriebenen HAPartition-Dienst auf. Sie sind darauf angewiesen, dass <literal>HAPartition</literal> Benachrichtigungen ausgibt, wenn verschiedene Nodes dem Cluster beitreten oder daraus austreten; basierend auf diesen Benachrichtigungen kann jeder Node im Cluster unabhängig (aber übereinstimmend) feststellen, ob er nun der Master Node ist und jetzt einen Dienst bereitstellen muss."
 
 #. Tag: title
 #: Clustering_Guide_Clustered_Singleton_Services.xml:22
@@ -120,7 +120,7 @@
 "it will be providing services. Depending on how complex the deployment of "
 "your service is and what sorts of startup activities it engages in, this "
 "could take a while, during which time the service is not being provided."
-msgstr "Wenn der Master Node ausfällt und ein anderer Node als Master übernimmt, muss Ihr Singleton-Dienst den gesamten Deployment-Prozess durchlaufen, bevor er Dienste liefert. Abhängig von der Komplexität des Deployments Ihres Dienstes und der Art von Aktivitäten beim Hochfahren, kann dies eine Weile dauern, währenddessen der Dienst nicht verfügbar ist."
+msgstr "Wenn der Master Node ausfällt und ein anderer Node als Master übernimmt, muss Ihr Singleton-Dienst den gesamten Deployment-Prozess durchlaufen, bevor er Dienste liefert. Abhängig von der Komplexität des Deployments Ihres Dienstes und der Art von Aktivitäten beim Hochfahren kann dies eine Weile dauern, währenddessen der Dienst nicht verfügbar ist."
 
 #. Tag: title
 #: Clustering_Guide_Clustered_Singleton_Services.xml:50
@@ -294,11 +294,8 @@
 "service could be primed and ready to go, just waiting for the controller to "
 "implement startSingleton() at which point it can immediately provide service."
 msgstr ""
-"Ein offensichtliches Manko hteilsbei diesems Verfahren ist, dass es nur für MBeans funkoniert. "
-"Vorteil ist, dass das obige Beispiel in <literal>deploy</literal> oder <literal>farm</literal> platziert werden kann und dadurch Hot Deployment und Farmed Deployment mögch ist. "
-"Auch könnten komplexe, zeitn fürup-Anforderungen den Start in unserem Beispiel möglicherweise in create()- oder start()-Methoden implementierwerden. "
-"JBoss ruft create() oder start() auf, sobald der Dienst deployt wird; es wartet nicht darauf, dass der Node zum Master Ne wird. "
-"Also kann der Dienst einsatzbereit braucht seinnoch , und nzu ur darauf warten, dass der Controller startSingleton() implementiert, woraufhin er sofort seinen Dienst bereitstellen kann."
+"Ein offensichtliches Manko bei diesem Verfahren ist, dass es nur für MBeans funkoniert. Vorteil ist, dass das obige Beispiel in <literal>deploy</literal> oder <literal>farm</literal> platziert werden kann und dadurch Hot Deployment und Farmed Deployment möglich ist. "
+"Auch könnten etwaige komplexe, zeitaufwendige Startup-Anforderungen möglicherweise in create()- oder start()-Methoden implementiert werden. JBoss ruft create() oder start() auf, sobald der Dienst deployt wird; es wartet nicht darauf, dass der Node zum Master Node wird. So kann der Dienst einsatzbereit sein und braucht nur noch darauf zu warten, dass der Controller startSingleton() implementiert, woraufhin er sofort seinen Dienst bereitstellen kann."
 
 #. Tag: para
 #: Clustering_Guide_Clustered_Singleton_Services.xml:72
@@ -370,7 +367,7 @@
 "singleton service's start/stop methods can take an argument, in this case "
 "the location of the directory the <literal>MainDeployer</literal> should "
 "deploy/undeploy."
-msgstr "Einige interessante Punkte hierbei. Erstens handelt es sich bei dem kontrollierten Dienst um den <literal>MainDeployer</literal>-Dienst – der Haupt-Deployment-Dienst in JBoss. Das heißt, es handelt sich um einen Dienst, der nicht mit der Absicht geschrieben wurde, ihn von einem <literal>HASingletonController</literal> kontrollieren zu lassen. Und dennoch funktioniert es! Zweitens, die Ziel-Start- und Ziel-Stop-Methoden lauten “deploy” und “undeploy”. Es gibt keine Anforderungen bezüglich bestimmter Namen, oder auch nur dass sie logisch “start”- und “stop”-Funktionalitäten besitzen. Hier ist die Funktionalität der aufgerufenen Methoden eher “do” und “undo”. Zuguterletzt, beachten Sie die “<literal>TargetStart(Stop)MethodArgument</literal>”-Attribute. Die start/stop-Methoden Ihres Singleton-Dienstes können ein Argument übernehmen, in diesem Fall der Speicherort des Verzeichnissses, für das der <literal>MainDeployer</literal> Deploy!
 ment/Undeployment durchführen soll."
+msgstr "Einige interessante Punkte hierbei. Erstens handelt es sich bei dem kontrollierten Dienst um den <literal>MainDeployer</literal>-Dienst – der Haupt-Deployment-Dienst in JBoss. Das heißt, es handelt sich um einen Dienst, der nicht mit der Absicht geschrieben wurde, ihn von einem <literal>HASingletonController</literal> kontrollieren zu lassen. Und dennoch funktioniert es! Zweitens, die Ziel-Start- und Ziel-Stop-Methoden lauten “deploy” und “undeploy”. Es gibt keine Anforderungen bezüglich bestimmter Namen, oder auch nur dass sie logisch “start”- und “stop”-Funktionalitäten besitzen. Hier ist die Funktionalität der aufgerufenen Methoden eher “do” und “undo”. Zuguterletzt, beachten Sie die “<literal>TargetStart(Stop)MethodArgument</literal>”-Attribute. Die start/stop-Methoden Ihres Singleton-Dienstes können ein Argument übernehmen, in diesem Fall den Speicherort des Verzeichnissses, für das der <literal>MainDeployer</literal> Deploy!
 ment/Undeployment durchführen soll."
 
 #. Tag: title
 #: Clustering_Guide_Clustered_Singleton_Services.xml:85
@@ -530,7 +527,7 @@
 "independently decide if it is now the master. The Foo service on each node "
 "does this by checking if they are the first member of the view – if they "
 "are, they are the master; if not, they're not. Simple as that."
-msgstr "Wann immer eine Änderung an der Cluster-Topologie des Foo-Dienstes erfolgt, ruft der <literal>HAPartition</literal>-Dienst einen Callback auf Foo auf, um über die neue Topologie zu informieren. Als beispielsweise also Foo auf D startete, erhielten die Foo-Dienste auf A, C und D Callbacks, die ihnen die neue Ansicht für Foo {A, C, D} mitteilten. Dieser Callback liefert jedem Node genügend Informationen, um zu entscheiden, ob er nun der Master ist. Der Foo-Dienst tut dies, indem er überprüft, ob er das erste Mitglied in der Ansicht ist – wenn er es ist, so ist er der Master; wenn nicht, dann ist er es nicht. So einfach."
+msgstr "Wann immer eine Änderung an der Cluster-Topologie des Foo-Dienstes erfolgt, ruft der <literal>HAPartition</literal>-Dienst einen Callback auf Foo auf, um über die neue Topologie zu informieren. Als beispielsweise also Foo auf D startete, erhielten die Foo-Dienste auf A, C und D Callbacks, die ihnen die neue Ansicht für Foo {A, C, D} mitteilten. Dieser Callback liefert jedem Node genügend Informationen, um zu entscheiden, ob er nun der Master ist. Der Foo-Dienst tut dies, indem er ganz einfach überprüft, ob er das erste Mitglied in der Ansicht ist – ist dies der Fall, so ist er der Master; ist er nicht das erste Mitglieder in der Ansicht, dann ist er nicht der Master."
 
 #. Tag: para
 #: Clustering_Guide_Clustered_Singleton_Services.xml:132
@@ -541,5 +538,5 @@
 "A, C and D would get a callback with a new view for Foo of {C, D, A}. C "
 "would remain the master – there's nothing magic about A that would cause it "
 "to become the master again just because it was before."
-msgstr "Falls A nun ausfällt oder beendet wird, erhält Foo auf C und D einen Callback mit der neuen Ansicht für Foo {C, D}. C wird daraufhin zum Master. Falls A neu startet, erhalten A, C und D einen Callback mit der neuen Ansicht für Foo {C, D, A}. C bleibt weiterhin Master – A wird nicht plötzlich durch einen Trick wieder Master, nur weil er das vorher auch war."
+msgstr "Falls A nun ausfällt oder beendet wird, erhält Foo auf C und D einen Callback mit der neuen Ansicht für Foo {C, D}. C wird daraufhin zum Master. Falls A neu startet, erhalten A, C und D einen Callback mit der neuen Ansicht für Foo {C, D, A}. C bleibt weiterhin Master – A wird nicht plötzlich wieder Master, nur weil er das vorher auch war."
 

Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_EJBs.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_EJBs.po	2009-04-21 07:06:05 UTC (rev 87607)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_EJBs.po	2009-04-21 07:12:18 UTC (rev 87608)
@@ -9,7 +9,7 @@
 "Project-Id-Version: Clustering_Guide_EJBs\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2009-01-20 02:37+0000\n"
-"PO-Revision-Date: 2009-04-09 14:53+1000\n"
+"PO-Revision-Date: 2009-04-14 09:36+1000\n"
 "Last-Translator: Hedda Peters <hpeters at redhat.com>\n"
 "Language-Team: \n"
 "MIME-Version: 1.0\n"
@@ -169,7 +169,7 @@
 "<emphasis role=\"bold\">home-load-balance-policy</emphasis> bezeichnet die "
 "zu verwendende Klasse des Home-Stubs, die bei der Verteilung der Aufrufe auf "
 "die Nodes des Clusters benutzt werden soll. Bei der Standardeinstellung wird "
-"das Proxy Aufrufe nach der <literal>RoundRobin</literal>-Weise verteilen. "
+"der Proxy Aufrufe nach der <literal>RoundRobin</literal>-Weise verteilen. "
 "Sie können aber auch Ihre eigene Klasse von Lastverteilungsrichtlinien "
 "implementieren oder die Klasse <literal>FirstAvailable</literal> verwenden, "
 "die stets den ersten verfügbaren Node verwendet, bis dies fehlschlägt."
@@ -462,7 +462,7 @@
 "literal>."
 msgstr ""
 "Bei <emphasis role=\"bold\">JndiName</emphasis> handelt es sich um ein "
-"optionales Attribut zur Bestimmung des JNDI-Namens unter dem dieser "
+"optionales Attribut zur Bestimmung des JNDI-Namens, unter dem dieser "
 "<literal>HASessionState</literal>-Dienst gebunden ist. Die "
 "Standardeinstellung lautet <literal>/HAPartition/Default</literal>."
 
@@ -666,7 +666,7 @@
 "configured properly to find your naming server. The RetryInterceptor will go "
 "through the following steps in attempting to determine the proper naming "
 "environment properties:"
-msgstr "Um den HA-Proxy wiederherzustellen, führt der RetryInterceptor einen Lookup in JNDI durch. Das bedeutet, dass er intern einen neuen InitialContext erstellt, und einen JNDI-Lookup durchführt. Doch damit der Lookup erfolgreich sein kann, muss der InitialContext ordnungsgemäß konfiguriert sein, um Ihren Naming-Server zu finden. Der RetryInterceptor führt im Versuch, die korrekten Naming-Umgebungseigenschaften festzustellen, die folgenden Schritte aus:"
+msgstr "Um den HA-Proxy wiederherzustellen, führt der RetryInterceptor einen Lookup in JNDI durch. Das bedeutet, dass er intern einen neuen InitialContext erstellt, und einen JNDI-Lookup durchführt. Doch damit der Lookup erfolgreich sein kann, muss der InitialContext ordnungsgemäß konfiguriert sein, um Ihren Naming-Server zu finden. Der RetryInterceptor führt beim Versuch, die korrekten Naming-Umgebungseigenschaften festzustellen, die folgenden Schritte aus:"
 
 #. Tag: para
 #: Clustering_Guide_EJBs.xml:133
@@ -723,7 +723,7 @@
 "never return. For many client applications, this possibility is "
 "unacceptable. As a result, JBoss doesn't make the RetryInterceptor part of "
 "its default client interceptor stacks for clustered EJBs."
-msgstr "Der RetryInterceptor ist in vielen Fällen nützlich, hat jedoch den Nachteil, dass er solange weiter versucht, den HA-Proxy in JNDI zu finden, bis es ihm gelingt. Falls er dies aus irgendeinem Grund nicht kann, wird dieser Prozess möglicherweise endlos weitergeführt werden, weshalb der EJB-Aufruf, der den RetryInterceptor ausgelöst hat, nie antworten würde. Für viele Client-Anwendungen wäre dies untragbar. Deshalb macht JBoss den RetryInterceptor nicht Teil seines Standard-Client-Interzeptorstapels für geclusterte EJBs."
+msgstr "Der RetryInterceptor ist in vielen Fällen nützlich, hat jedoch den Nachteil, dass er solange weiter versucht, den HA-Proxy in JNDI zu finden, bis es ihm gelingt. Falls dies aus irgendeinem Grund nicht möglich ist, wird dieser Prozess ggf. endlos weitergeführt werden, weshalb der EJB-Aufruf, der den RetryInterceptor ausgelöst hat, nie antworten würde. Für viele Client-Anwendungen wäre dies untragbar. Deshalb nimmt JBoss den RetryInterceptor nicht als Teil seines Standard-Client-Interzeptorstapels für geclusterte EJBs auf."
 
 #. Tag: para
 #: Clustering_Guide_EJBs.xml:156
@@ -744,7 +744,7 @@
 "The downside of the SingleRetryInterceptor is that if the retry attempt is "
 "made during a portion of a cluster restart where no servers are available, "
 "the retry will fail and no further attempts will be made."
-msgstr "Der Nachteil des SingleRetryInterceptor liegt darin, dass wenn der Retry-Versuch während einer Phase des Cluster-Neustarts erfolgt, in der keine Server verfügbar sind, dann schlägt der Retry fehl, und es werden keine weiteren Versuche unternommen."
+msgstr "Der Nachteil des SingleRetryInterceptors liegt darin, dass wenn der Retry-Versuch während einer Phase des Cluster-Neustarts erfolgt, in der keine Server verfügbar sind, dann schlägt der Retry fehl, und es werden keine weiteren Versuche unternommen."
 
 #. Tag: title
 #: Clustering_Guide_EJBs.xml:169
@@ -952,7 +952,7 @@
 "true, since replication involves serializing the bean, and preparing for and "
 "recovering from serialization is a common reason for implementing the "
 "callback methods."
-msgstr "<literal>replicationIsPassivation</literal> legt fest, ob der Cache eine Replikation als äquivalent zu einer Passivierung betrachten soll, und @PrePassivate und @PostActivate-Callbacks auf dem Bean aufrufen soll. Standardmäßig \"true\", denn Replikation beinhaltet die Serialisierung eines Beans, und die Vorbereitung auf bzw. das Wiederherstellen nach Serialisierung sind gängige Gründe für die Implementierung der Callback-Methoden."
+msgstr "<literal>replicationIsPassivation</literal> legt fest, ob der Cache eine Replikation als äquivalent zu einer Passivierung betrachten soll, und @PrePassivate und @PostActivate-Callbacks auf dem Bean aufrufen soll. Standardmäßig \"true\", denn Replikation beinhaltet die Serialisierung eines Beans, und die Vorbereitung auf bzw. das Wiederherstellen nach Serialisierung sind übliche Gründe für die Implementierung der Callback-Methoden."
 
 #. Tag: para
 #: Clustering_Guide_EJBs.xml:209
@@ -1010,7 +1010,7 @@
 "replicated. With EJB3, the mechanism is a little more formal; instead of "
 "just exposing a method with a known signature, an EJB3 SFSB must implement "
 "the org.jboss.ejb3.cache.Optimized interface:"
-msgstr "Wie auch für EJB 2.0 geclusterte SFSBs, stellt JBoss ein Verfahren bereit, mit Hilfe dessen eine Bean-Implementierung eine Methode offenlegen kann, die der Container aufrufen kann zum Prüfen, ob der Bean-Status nicht \"dirty\" ist nach einer Anfrage und nicht repliziert werden muss. Bei EJB3 ist dies Verfahren etwas umständlicher; statt einfach eine Methode mit einer bekannten Signatur offenzulegen, muss ein EJB3 SFSB die org.jboss.ejb3.cache.Optimized-Schnittstelle implementieren:"
+msgstr "Wie auch für EJB 2.0 geclusterte SFSBs, stellt JBoss ein Verfahren bereit, wodurch eine Bean-Implementierung eine Methode offenlegen kann, die der Container aufrufen kann zum Prüfen, ob der Bean-Status nicht \"dirty\" ist nach einer Anfrage, und nicht repliziert werden muss. Bei EJB3 ist dies Verfahren etwas umständlicher; statt einfach eine Methode mit einer bekannten Signatur offenzulegen, muss ein EJB3 SFSB die org.jboss.ejb3.cache.Optimized-Schnittstelle implementieren:"
 
 #. Tag: programlisting
 #: Clustering_Guide_EJBs.xml:224

Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Entity_EJBs.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Entity_EJBs.po	2009-04-21 07:06:05 UTC (rev 87607)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_Entity_EJBs.po	2009-04-21 07:12:18 UTC (rev 87608)
@@ -9,7 +9,7 @@
 "Project-Id-Version: Clustering_Guide_Entity_EJBs\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2009-01-20 02:37+0000\n"
-"PO-Revision-Date: 2009-04-09 14:54+1000\n"
+"PO-Revision-Date: 2009-04-21 12:23+1000\n"
 "Last-Translator: Hedda Peters <hpeters at redhat.com>\n"
 "Language-Team: \n"
 "MIME-Version: 1.0\n"
@@ -217,7 +217,7 @@
 "Um Rundreisen zur Datenbank zu vermeiden, können Sie einen Cache-Speicher für "
 "Ihre Entitys verwenden. JBoss EJB 3.0 Entity-Beans sind durch Hibernate implementiert, "
 "welches Support für einen Cache der zweiten Ebene (\"Second-Level Cache\") "
-"bietet. Der Hibernate-Setup, der für die Implementierung von JBoss EJB 3.0 "
+"bietet. Das Hibernate-Setup, das für die Implementierung von JBoss EJB 3.0 "
 "benutzt wird, verwendet JBoss Cache als seine zu Grunde liegende Cache-Implementierung. Der Cache bietet die folgenden Funktionalitäten:"
 
 #. Tag: para
@@ -247,7 +247,7 @@
 "If you remove an entity bean instance from the database via the entity "
 "manager the entity will removed from the cache."
 msgstr ""
-"Wenn Sie eine eine Bean-Instanz aus der Datenbank mittels des Entity-"
+"Wenn Sie eine Bean-Instanz aus der Datenbank mittels des Entity-"
 "Managers entfernen, so wird die Entity aus dem Cache entfernt."
 
 #. Tag: para
@@ -522,7 +522,7 @@
 "prefix. This is not a particularly friendly region prefix if you need to use "
 "it to set up specialized eviction regions (see below), so specifying your "
 "own region prefix is recommended."
-msgstr "Falls Sie kein “region_prefix” angeben, wird JBoss automatisch eines für Sie liefern, zusammengesetzt aus dem Namen des EAR (falls vorhanden) und dem Namen des JAR, welches die persistence.xml enthält. So würde beispielweise ein persistence.xml, gepackt in foo.ear, bar.jar, das region_prefix \"foo_ear,bar_jar\" erhalten. Dies ist kein besonders nutzerfreundliches region_prefix, falls Sie es zum Einrichten von spezialisierten Eviction-Bereichen verwenden müssen (siehe unten). Daher empfehlen wir, Ihr eigenes region_prefix zu spezifizieren."
+msgstr "Falls Sie kein “region_prefix” angeben, wird JBoss automatisch eines für Sie erstellen, zusammengesetzt aus dem Namen des EAR (falls vorhanden) und dem Namen des JAR, welches die persistence.xml enthält. So würde beispielweise ein persistence.xml, gepackt in foo.ear, bar.jar, das region_prefix \"foo_ear,bar_jar\" erhalten. Dies ist kein besonders nutzerfreundliches region_prefix, falls Sie es zum Einrichten von spezialisierten Eviction-Bereichen verwenden müssen (siehe unten). Daher empfehlen wir, Ihr eigenes region_prefix zu spezifizieren."
 
 #. Tag: para
 #: Clustering_Guide_Entity_EJBs.xml:105
@@ -747,7 +747,7 @@
 "collections of scalar values) of specified queries. Here we show a simple "
 "example of annotating a bean with a named query, also providing the "
 "Hibernate-specific hints that tells Hibernate to cache the query."
-msgstr "Die EJB3 Query API stellt auch einen Weg bereit, durch den Sie im Cache der zweiten Ebene die Ergebnisse bestimmter Abfragen speichern können (z. B. Collections von Primärschlüsseln von Entity-Beans, oder Collections von skalaren Werten). Wir zeigen Ihnen hier ein einfaches Beispiel für das Annotieren eines Beans mit einer benannten Abfrage, und liefern Hibernate-spezifische Hinweise (\"Hints\"), die Hibernate mitteilen, die Abfrage zu cachen."
+msgstr "Die EJB3 Query API stellt auch einen Weg bereit, durch den Sie die Ergebnisse bestimmter Abfragen im Cache der zweiten Ebene speichern können (z. B. Collections von Primärschlüsseln von Entity-Beans, oder Collections von skalaren Werten). Wir zeigen Ihnen hier ein einfaches Beispiel für das Annotieren eines Beans mit einer benannten Abfrage, und liefern Hibernate-spezifische Hinweise (\"Hints\"), die Hibernate mitteilen, die Abfrage zu cachen."
 
 #. Tag: para
 #: Clustering_Guide_Entity_EJBs.xml:126
@@ -819,7 +819,7 @@
 "can set up separate eviction handling for your query results. So, if the "
 "region prefix were set to myprefix in persistence.xml, you could, for "
 "example, create this sort of eviction handling:"
-msgstr "Standardmäßig speichert Hibernate Abfrageergebnisse im JBoss-Cache in einem Bereich namens {region_prefix}/org/hibernate/cache/StandardQueryCache. Darauf aufbauend können Sie die Handhabung der Eviction separat einstellen für Ihre Abfrageergebnisse. Angenommen, das region_prefix in persistence.xml ist auf \"myprefix\" gesetzt, dann könnten Sie die Handhabung der Eviction z. B. folgenderweise einstellen:"
+msgstr "Standardmäßig speichert Hibernate Abfrageergebnisse im JBoss-Cache in einem Bereich namens {region_prefix}/org/hibernate/cache/StandardQueryCache. Darauf aufbauend können Sie die Handhabung der Eviction separat einstellen für Ihre Abfrageergebnisse. Angenommen, das region_prefix in persistence.xml ist auf \"myprefix\" gesetzt, dann könnten Sie die Handhabung der Eviction z. B. folgendermaßen einstellen:"
 
 #. Tag: programlisting
 #: Clustering_Guide_Entity_EJBs.xml:142

Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_HTTP.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_HTTP.po	2009-04-21 07:06:05 UTC (rev 87607)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_HTTP.po	2009-04-21 07:12:18 UTC (rev 87608)
@@ -9,7 +9,7 @@
 "Project-Id-Version: Clustering_Guide_HTTP\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2009-01-20 02:37+0000\n"
-"PO-Revision-Date: 2009-04-09 14:54+1000\n"
+"PO-Revision-Date: 2009-04-21 14:45+1000\n"
 "Last-Translator: Hedda Peters <hpeters at redhat.com>\n"
 "Language-Team: \n"
 "MIME-Version: 1.0\n"
@@ -101,7 +101,7 @@
 "not to replicate HTTP sessions because all critical state is stored in a "
 "database. In other situations, losing a client session is not acceptable "
 "and, in this case, session state replication is the price one has to pay."
-msgstr "Ein Lastverteiler verfolgt die HTTP-Anfragen, und je nachdem, welche Session mit der Anfrage verbunden ist, leitet er diese an den betreffenden Node weiter. Man spricht in diesem Zusammenhang von einem Lastverteiler mit \"Sticky Sessions\": Wenn eine Session einmal an einem Node erstellt wurde, so werden alle zukünftigen Anfragen von demselben Node bearbeitet. Das Verwenden eines \"Sticky Sessions\" unterstützenden Lastverteilers, bei dem Ihre Web-Applikation nicht für Session-Replikation konfiguriert sein muss, ermöglicht Ihnen ein genaues Skalieren, indem die Kosten für Session-Statusreplikation vermieden werden: jede Abfrage wird stets vom selben Node bearbeitet. Falls jedoch ein Node ausfällt, so fällt auch der Status sämtlicher von ihm bearbeiteter Client-Sessions aus (z. B. die Einkaufswagen) und Kunden werden sich wahrscheinlich auf einem anderen Node neu einloggen und eine neue Sitzung starten müssen. In vielen Situationen ist es vertretbar, auf die!
  Replikation von HTTP-Sessions zu verzichten, da alle wichtigen Statusinformationen in der Datenbank gespeichert werden. In anderen Situationen hingegen ist es inakzeptabel eine Client-Session zu verlieren, und es empfiehlt sich, die Session-Statusreplikation anzuwenden."
+msgstr "Ein Lastverteiler verfolgt HTTP-Anfragen nach, und je nachdem, welche Session mit der Anfrage verbunden ist, leitet er diese an den betreffenden Node weiter. Man spricht in diesem Zusammenhang von einem Lastverteiler mit \"Sticky Sessions\": Wenn eine Session einmal an einem Node erstellt wurde, so werden alle zukünftigen Anfragen von demselben Node bearbeitet. Das Verwenden eines \"Sticky Sessions\" unterstützenden Lastverteilers, bei dem Ihre Web-Applikation nicht für Session-Replikation konfiguriert sein muss, ermöglicht Ihnen ein genaues Skalieren, indem die Kosten für Session-Statusreplikation vermieden werden: jede Abfrage wird stets vom selben Node bearbeitet. Falls jedoch ein Node ausfällt, so fällt auch der Status sämtlicher von ihm bearbeiteter Client-Sessions aus (z. B. die Einkaufswagen) und Kunden werden sich wahrscheinlich auf einem anderen Node neu einloggen und eine neue Sitzung starten müssen. In vielen Situationen ist es vertretbar, auf di!
 e Replikation von HTTP-Sessions zu verzichten, da alle wichtigen Statusinformationen in der Datenbank gespeichert werden. In anderen Situationen hingegen ist es inakzeptabel eine Client-Session zu verlieren, und es empfiehlt sich, die Session-Statusreplikation anzuwenden."
 
 #. Tag: title
 #: Clustering_Guide_HTTP.xml:26
@@ -145,7 +145,7 @@
 "<literal>http://httpd.apache.org/</literal> herunterladen. Die Installation "
 "ist unkompliziert und erfordert keine spezielle Konfiguration. Da es mehrere "
 "Versionen von Apache gibt, empfehlen wir den Download von Version 2.0.x. In "
-"den folgenden Abschnitten gehen wir davon aus, dass Sie Apache im"
+"den folgenden Abschnitten gehen wir davon aus, dass Sie Apache im "
 "<literal>APACHE_HOME</literal>-Verzeichnis installiert haben."
 
 #. Tag: para
@@ -595,7 +595,7 @@
 "A non-loadbalanced setup with a single node requires a <literal>worker."
 "list=node1</literal> entry."
 msgstr ""
-"Eine nicht-lastverteilte Konfiguration mit einem einzelnen Node erfordert den Eintrag"
+"Eine nicht-lastverteilte Konfiguration mit einem einzelnen Node erfordert den Eintrag "
 "<literal>worker.list=node1</literal>."
 
 #. Tag: title
@@ -717,7 +717,7 @@
 "refer to the JBoss wiki page at <literal>http://wiki.jboss.org/wiki/Wiki.jsp?"
 "page=UsingMod_jk1.2WithJBoss</literal>."
 msgstr ""
-"Aktuelle Information zur Benutzung von mod_jk 1.2 mit JBoss Tomcat finden "
+"Aktuelle Informationen zur Benutzung von mod_jk 1.2 mit JBoss Tomcat finden "
 "Sie auf der JBoss Wiki-Seite unter <literal>http://wiki.jboss.org/wiki/Wiki."
 "jsp?page=UsingMod_jk1.2WithJBoss</literal>."
 
@@ -935,11 +935,11 @@
 "session replication is needed (see later). Otherwise, they are default to "
 "<literal>false</literal>."
 msgstr ""
-"The <emphasis role=\"bold\">UseMarshalling</emphasis> und <emphasis role="
+"Die <emphasis role=\"bold\">UseMarshalling</emphasis> und <emphasis role="
 "\"bold\">InactiveOnStartup</emphasis>-Attribute müssen denselben Wert "
 "besitzen. Die Einstellung muss <literal>true</literal> lauten, falls "
-"<literal>FIELD</literal>-Ebene Session-Replikation benötigt wird (siehe "
-"später). Andernfalls lautet die Standardeinstellung <literal>false</literal>."
+"<literal>FIELD</literal>-Ebene Session-Replikation benötigt wird (dazu"
+"später mehr). Andernfalls lautet die Standardeinstellung <literal>false</literal>."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:192
@@ -1160,7 +1160,7 @@
 "attributes are separately deserialized on the remote nodes, each Person "
 "object will now have a reference to its own Address object; the Address "
 "object will no longer be shared."
-msgstr "<emphasis role=\"bold\">ATTRIBUTE</emphasis>: Replikation wird nur durchgeführt für \"dirty\" Attribute in der Session sowie manche Session-Daten, wie der Zeitstempel des letzten Zugriffs. Für Sessions, die große Mengen an Daten enthalten, kann diese Option die Replikations-Performance verbessern. Attribute werden jedoch separat serialisiert, wenn also eine gemeinsame Referenz zwischen Objekten existiert, die in den Attributen gespeicherten sind, so wird diese gemeinsame Referenz auf Remote-Nodes ggf. zerstört. Nehmen wir beispielsweise an, ein Personenobjekt, gespeichert unter dem Schlüssel \"Ehemann\", hat eine Referenz zu einer Adresse, während ein anderes Personenobjekt, gespeichert unter dem Schlüssel \"Ehefrau\", eine Referenz zu demselben Adressobjekt besitzt. Wenn nun die \"Ehemann\"- und \"Ehefrau\"-Attribute auf den Remote-Nodes separat deserialisiert werden, besitzt danach jedes Personenobjekt eine Referenz zu seinem eigenen Adressobjekt; das Adre!
 ssobjekt wird nicht länger geteilt."
+msgstr "<emphasis role=\"bold\">ATTRIBUTE</emphasis>: Replikation wird nur durchgeführt für \"dirty\" Attribute in der Session sowie manche Session-Daten, wie der Zeitstempel des letzten Zugriffs. Für Sessions, die große Mengen an Daten enthalten, kann diese Option die Replikations-Performance verbessern. Attribute werden jedoch separat serialisiert, wenn also gemeinsam verwendete Referenzen zwischen Objekten existieren, die in den Attributen gespeichert sind, so werden diese gemeinsamen Referenzen auf Remote-Nodes ggf. zerstört. Nehmen wir beispielsweise an, ein Personenobjekt, gespeichert unter dem Schlüssel \"Ehemann\", hat eine Referenz zu einer Adresse, während ein anderes Personenobjekt, gespeichert unter dem Schlüssel \"Ehefrau\", eine Referenz zu demselben Adressobjekt besitzt. Wenn nun die \"Ehemann\"- und \"Ehefrau\"-Attribute auf den Remote-Nodes separat deserialisiert werden, besitzt danach jedes Personenobjekt eine Referenz zu seinem eigenen Adressobjek!
 t; das Adressobjekt wird nicht länger gemeinsam verwendet."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:238
@@ -1205,7 +1205,7 @@
 "section, we will discuss exactly how the FIELD level replication works."
 msgstr ""
 "Wenn Ihre Sessions in der Regel eher klein sind, so ist SESSION die "
-"geeignetere Richtlinie. Falls Ihre Session größer ist und auf einige Teile "
+"geeignetere Richtlinie. Falls Ihre Sessions größer sind und auf einige Teile "
 "eher selten zugegriffen wird, so ist die ATTRIBUTE-Replikation effektiver. "
 "Falls Ihre Anwendung sehr große Datenobjekte in Session-Attributen besitzt "
 "und nur Felder in diesen Objekten oft verändert werden, dann ist die FIELD-"
@@ -1232,7 +1232,7 @@
 "Die Replikation auf FIELD-Ebene repliziert nur veränderte Datenfelder "
 "innerhalb von Objekten, die in der Session gespeichert werden. Dies könnte "
 "möglicherweise den Datenverkehr zwischen den geclusterten Nodes drastisch "
-"senken und somit die Leistung des Gesamt-Clusters verbessern. Um die Replikation auf FIELD-Ebene zu verwenden, müssen Sie zunächst einmal Ihre Java-Klasse vorbereiten (d. h. den Bytecode anreichern, sog \"Bytecode Enhancement\"), so dass der Session-Cache erkennen kann, wenn Felder in gecachten Objekten verändert wurden und repliziert werden müssen. "
+"senken und somit die Leistung des Clusters insgesamt verbessern. Um die Replikation auf FIELD-Ebene zu verwenden, müssen Sie zunächst einmal Ihre Java-Klasse vorbereiten (d. h. den Bytecode anreichern, sog \"Bytecode Enhancement\"), so dass der Session-Cache erkennen kann, wenn Felder in gecachten Objekten verändert wurden und repliziert werden müssen. "
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:262
@@ -1375,7 +1375,7 @@
 "step is only need if the JDK 1.4 style annotations are used; if JDK 5 "
 "annotations are used it is not necessary. Here is an example on how to "
 "invoke those commands from command line."
-msgstr "Nachdem Sie Ihre Klassen annotiert haben, werden Sie einen vorbereitenden Schritt ausführen müssen, in dem Sie für Ihre Klassen Bytecode-Anreicherung durchführen für die Verwendung durch TreeCacheAop. Sie werden den JBoss AOP Pre-Compiler <literal>annotationc</literal> und Post-Compiler <literal>aopc</literal> verwenden müssen, um den Quellcode oben vor und nach der Kompilierung durch den Java-Compiler zu bearbeiten. Der \"annotationc\"-Schritt ist nur nötig bei Verwendung von Annotationen im JDK 1.4 Stil, wenn JDK 5 Annotationen verwendet werden, ist er nicht nötig. Nachfolgend sehen Sie ein Beispiel dafür, wie Sie diese Befehle von der Befehlszeile aufrufen."
+msgstr "Nachdem Sie Ihre Klassen annotiert haben, werden Sie einen vorbereitenden Schritt ausführen müssen, in dem Sie für Ihre Klassen Bytecode-Anreicherung durchführen für die Verwendung durch TreeCacheAop. Sie werden den JBoss AOP Pre-Compiler <literal>annotationc</literal> und Post-Compiler <literal>aopc</literal> verwenden müssen, um den obigen Quellcode vor und nach der Kompilierung durch den Java-Compiler zu bearbeiten. Der \"annotationc\"-Schritt ist nur nötig bei Verwendung von Annotationen im JDK 1.4 Stil – wenn JDK 5 Annotationen verwendet werden, ist er nicht nötig. Nachfolgend sehen Sie ein Beispiel dafür, wie Sie diese Befehle von der Befehlszeile aufrufen."
 
 #. Tag: programlisting
 #: Clustering_Guide_HTTP.xml:291
@@ -1584,7 +1584,7 @@
 "session. The <literal>org.jboss.cache</literal> and <literal>org.jboss.web</"
 "literal> logging categories provide additional insight into session "
 "replication useful for debugging purposes."
-msgstr "Diese Ausgabe zeigt zwei separate Web-Sessions, in einer Anwendung namens <emphasis>quote</emphasis>, die mittels JBossCache geteilt werden. Das Beispiel verwendet eine <literal>replication-granularity</literal> von <literal>session</literal>. Wäre eine Replikation auf <literal>attribute</literal>-Ebene verwendet werden, so wären weitere Eintragungen zu den einzelnen replizierten Session-Attributen vorhanden. In jedem Falle werden die replizierten Werte in einem nicht einsehbaren <literal>MarshelledValue</literal>-Container gespeichert. Es gibt derzeit keine Tools, mit denen Sie die Inhalte der replizierten Session-Werte einsehen könnten. Falls Sie keine Ausgabe sehen, war die Anwendung entweder nicht ordnungsgemäß als <literal>distributable</literal> gekennzeichnet oder Sie haben keinen Teil der Anwendung aufgerufen, der Werte in der HTTP-Session ablegt. Die <literal>org.jboss.cache</literal> und <literal>org.jboss.web</literal>-Protokollkategorien bieten zusÃ!
 ¤tzlichen Einblick in die Replikation der Session, was inbesondere bei der Fehlersuche und -beseitigung hilfreich sein kann."
+msgstr "Diese Ausgabe zeigt zwei separate Web-Sessions in einer Anwendung namens <emphasis>quote</emphasis>, die mittels JBossCache geteilt werden. Das Beispiel verwendet eine <literal>replication-granularity</literal> von <literal>session</literal>. Wäre eine Replikation auf <literal>attribute</literal>-Ebene verwendet werden, so wären weitere Eintragungen zu den einzelnen replizierten Session-Attributen vorhanden. In jedem Fall werden die replizierten Werte in einem nicht einsehbaren <literal>MarshelledValue</literal>-Container gespeichert. Es gibt derzeit keine Tools, mit denen Sie die Inhalte der replizierten Session-Werte einsehen könnten. Falls Sie keine Ausgabe sehen, war die Anwendung entweder nicht ordnungsgemäß als <literal>distributable</literal> gekennzeichnet oder Sie haben keinen Teil der Anwendung aufgerufen, der Werte in der HTTP-Session ablegt. Die <literal>org.jboss.cache</literal> und <literal>org.jboss.web</literal>-Protokollkategorien bieten zusät!
 zlichen Einblick in die Replikation der Session, was inbesondere bei der Fehlersuche und -beseitigung hilfreich sein kann."
 
 #. Tag: title
 #: Clustering_Guide_HTTP.xml:338
@@ -1647,7 +1647,7 @@
 "http.HttpSessionListener</package>, <package>javax.servlet.http."
 "HttpSessionAttributeListener</package>, and <package>javax.servlet.http."
 "HttpSessionBindingListener interfaces</package>."
-msgstr "Dieser Abschnitt stellt das Konzept der Richtlinie für geclusterte Session-Benachrichtigung vor, welche bestimmt, ob die Servlet-Spec-Benachrichtigungen hinsichtlich Session-Ereignissen an den lokalen Cluster-Node gesendet werden dürfen. Diese Benachrichtigungen werden an Implementierungen der <package>javax.servlet.http.HttpSessionListener</package>, <package>javax.servlet.http.HttpSessionAttributeListener</package>, und <package>javax.servlet.http.HttpSessionBindingListener interfaces</package> gesendet."
+msgstr "Dieser Abschnitt stellt das Konzept der Richtlinie für geclusterte Session-Benachrichtigung vor, die bestimmt, ob die Servlet-Spec-Benachrichtigungen hinsichtlich Session-Ereignissen an den lokalen Cluster-Node gesendet werden dürfen. Diese Benachrichtigungen werden an Implementierungen der <package>javax.servlet.http.HttpSessionListener</package>, <package>javax.servlet.http.HttpSessionAttributeListener</package>, und <package>javax.servlet.http.HttpSessionBindingListener interfaces</package> gesendet."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:352
@@ -1671,7 +1671,7 @@
 "classname>, which implements the same behavior except for undeployment "
 "situations in which no <classname>HttpSessionListener</classname> and "
 "<classname>HttpSessionAttributeListener</classname> notifications are sent."
-msgstr "Obwohl es möglich ist, <classname>ClusteredSessionNotificationPolicy</classname> für fallspezifische Anpassungen zu implementieren, bietet JBoss <classname>LegacyClusteredSessionNotificationPolicy</classname>, was die Verhaltensweisen in älteren JBoss Versionen implementiert (Standard), sowie <classname>IgnoreUndeployLegacyClusteredSessionNotificationPolicy</classname>, was dieselben Verhaltensweisen implementiert mit Ausnahme von Undeployment-Situationen, in denen keine <classname>HttpSessionListener</classname> und <classname>HttpSessionAttributeListener</classname>-Benachrichtigungen gesendet werden."
+msgstr "Es ist zwar möglich, <classname>ClusteredSessionNotificationPolicy</classname> für fallspezifische Anpassungen zu implementieren, aber JBoss bietet die <classname>LegacyClusteredSessionNotificationPolicy</classname>, was die Verhaltensweisen in älteren JBoss Versionen implementiert (Standard), sowie <classname>IgnoreUndeployLegacyClusteredSessionNotificationPolicy</classname>, was dieselben Verhaltensweisen implementiert mit Ausnahme von Undeployment-Situationen, in denen keine <classname>HttpSessionListener</classname> und <classname>HttpSessionAttributeListener</classname>-Benachrichtigungen gesendet werden."
 
 #. Tag: para
 #: Clustering_Guide_HTTP.xml:357
@@ -1700,7 +1700,7 @@
 msgid ""
 "Using jboss-web.xml to set the policy per application using the following "
 "format:"
-msgstr "Verwenden Sie jboss-web.xml, um die Richtline pro Anwendung einzustellen unter Verwendung des folgenden Formats:"
+msgstr "Verwenden Sie jboss-web.xml, um die Richtline pro Anwendung einzustellen. Benutzen Sie dafür folgendes Format:"
 
 #. Tag: programlisting
 #: Clustering_Guide_HTTP.xml:370

Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JBoss_Cache_JGroups.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JBoss_Cache_JGroups.po	2009-04-21 07:06:05 UTC (rev 87607)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JBoss_Cache_JGroups.po	2009-04-21 07:12:18 UTC (rev 87608)
@@ -9,7 +9,7 @@
 "Project-Id-Version: Clustering_Guide_JBoss_Cache_JGroups\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2009-01-20 02:37+0000\n"
-"PO-Revision-Date: 2009-04-09 14:55+1000\n"
+"PO-Revision-Date: 2009-04-21 17:10+1000\n"
 "Last-Translator: Hedda Peters <hpeters at redhat.com>\n"
 "Language-Team: \n"
 "MIME-Version: 1.0\n"
@@ -46,8 +46,8 @@
 "deploying an application that has special network or performance "
 "requirements."
 msgstr ""
-"Der JBoss AS kommt mit einem ordentlichen Satz von voreingestellten JGroups "
-"und JBossCache MBean-Konfigurationen. Die meisten Anwendungen funktionieren "
+"Der JBoss AS wird mit einem vernünftigen Satz von voreingestellten JGroups "
+"und JBossCache MBean-Konfigurationen ausgeliefert. Die meisten Anwendungen funktionieren "
 "hervorragend mit den voreingestellten MBean-Konfigurationen. Anpassungen "
 "sind nur notwendig, wenn Sie eine Anwendung ausführen, die spezielle "
 "Anforderungen an das Netzwerk oder die Performance stellt."
@@ -272,7 +272,7 @@
 msgid ""
 "The following common properties are exposed by all of the JGroups protocols "
 "discussed below:"
-msgstr "Die folgenden gängigen Eigenschaften werden von allen unten behandelten JGroups-Protokollen offengelegt:"
+msgstr "Die folgenden gängigen Eigenschaften werden von allen unten erklärten JGroups-Protokollen offengelegt:"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:43
@@ -311,7 +311,7 @@
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:57
 #, no-c-format
 msgid "Transport Protocols"
-msgstr "Transportprotokolle (\"Transport Protocols\")"
+msgstr "Transportprotokolle"
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:58
@@ -483,7 +483,7 @@
 "addresses or interface names. E.g. \"<literal>192.168.5.1,eth1,127.0.0.1</"
 "literal>\"."
 msgstr ""
-"<emphasis role=\"bold\">receive_interfaces</emphasis> legt eine Liste von Schnittstellen fest, auf denen Multicasts empfangen werden. Der Multicast-Empfangs-Socket wird auf all diesen Schnittstellen lauschen. Es handelt sich hierbei um eine kommagetrennt Liste mit IP-Adressen oder Schnittstellennamen, z. B. \"<literal>192.168.5.1,eth1,127.0.0.1</"
+"<emphasis role=\"bold\">receive_interfaces</emphasis> legt eine Liste von Schnittstellen fest, auf denen Multicasts empfangen werden. Der Multicast-Empfangs-Socket wird auf all diesen Schnittstellen lauschen. Es handelt sich hierbei um eine kommagetrennte Liste mit IP-Adressen oder Schnittstellennamen, z. B. \"<literal>192.168.5.1,eth1,127.0.0.1</"
 "literal>\"."
 
 #. Tag: para
@@ -718,7 +718,7 @@
 "millis for a socket creation. When doing the initial discovery, and a peer "
 "hangs, don't wait forever but go on after the timeout to ping other members. "
 "Reduces chances of *not* finding any members at all. The default is 2000."
-msgstr "<emphasis role=\"bold\">sock_conn_timeout</emphasis> bestimmt die maximale Zeit (in Millisekunden) für die Erstellung eines Sockets. Wenn beim Durchführen der ersten Discovery ein Peer hängenbleibt, warten Sie nicht ewig, sondern fahren nach dem Timeout damit fort, andere Mitglieder anzupingen. Dies verringert die Wahrscheinlichkeit, überhaupt keine Mitglieder zu finden. Der voreingestellte Wert lautet 2000."
+msgstr "<emphasis role=\"bold\">sock_conn_timeout</emphasis> bestimmt die maximale Zeit (in Millisekunden) für die Erstellung eines Sockets. Wenn beim Durchführen der ersten Discovery ein Peer hängenbleibt, wird nicht endlos gewartet, sondern nach dem Timeout damit fortgefahren, andere Mitglieder anzupingen. Dies verringert die Wahrscheinlichkeit, überhaupt keine Mitglieder zu finden. Der voreingestellte Wert lautet 2000."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:203
@@ -902,7 +902,7 @@
 "joiner determines the coordinator from the responses, and sends a JOIN "
 "request to it (handled by). If nobody responds, we assume we are the first "
 "member of a group."
-msgstr "PING ist ein Discovery-Protokoll und funktioniert entweder durch das Übertragen von multiplen PING-Anfragen an eine IP-Multicast-Adresse (Multicasting), oder durch Verbinden mit einem Gossip-Router. Folglich ist PING normalerweise über den UDP- oder TUNNEL-Transportprotokolls angesiedelt. Jeder Node antwortet mit einem Paket {C, A}, wobei C = die Adresse des Koordinators und A = seine eigene Adresse ist. Nach Erhalt einer Antwort durch Timeout Milliseconds oder num_initial_members bestimmt der neu eintretende Node mit Hilfe der Antworten den Koordinator und sendet ihm eine JOIN-Anfrage. Falls niemand antwortet, nehmen wir an, dass wir das erste Mitglied einer Gruppe sind."
+msgstr "PING ist ein Discovery-Protokoll und funktioniert entweder durch das Übertragen von multiplen PING-Anfragen an eine IP-Multicast-Adresse (Multicasting), oder durch Verbinden mit einem Gossip-Router. Folglich ist PING normalerweise über den UDP- oder TUNNEL-Transportprotokolls angesiedelt. Jeder Node antwortet mit einem Paket {C, A}, wobei C = die Adresse des Koordinators und A = seine eigene Adresse ist. Nach Erhalt einer Antwort durch Timeout Milliseconds oder num_initial_members bestimmt der neu eintretende Node mit Hilfe der Antworten den Koordinator und sendet ihm eine JOIN-Anfrage. Falls niemand antwortet, nimmt er an, dass er das erste Mitglied einer Gruppe ist."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:266
@@ -953,7 +953,7 @@
 "The available attributes in the <literal>PING</literal> element are listed "
 "below."
 msgstr ""
-"Die verfügbaren Attribute im <literal>PING</literal>-Element sind unten "
+"Die verfügbaren Attribute im <literal>PING</literal>-Element sind nachfolgend"
 "aufgeführt."
 
 #. Tag: para
@@ -1007,9 +1007,7 @@
 msgid ""
 "<emphasis role=\"bold\">gossip_refresh</emphasis> specifies the interval (in "
 "milliseconds) for the lease from the GossipRouter. The default is 20000."
-msgstr ""
-"<emphasis role=\"bold\">gossip_refresh</emphasis> bestimmt (in "
-"Millisekunden) den Intervall der Lease vom GossipRouter. Der voreingestellte Wert ist 20000."
+msgstr "<emphasis role=\"bold\">gossip_refresh</emphasis> bestimmt den Intervall der Lease vom GossipRouter (in Millisekunden). Der voreingestellte Wert ist 20000."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:301
@@ -1047,7 +1045,7 @@
 "elapsed or the <literal>num_initial_members</literal> responses have been "
 "received."
 msgstr ""
-"Die Discovery-Phase beginnt erneut, wenn die <literal>timeout</literal> ms "
+"Die Discovery-Phase beginnt erneut, wenn die <literal>timeout</literal> Millisekunden "
 "vergangen sind oder die <literal>num_initial_members</literal> Rückmeldungen "
 "empfangen wurden."
 
@@ -1181,7 +1179,7 @@
 "connect to hosta:2300, hosta:2301, hosta:2302, hostb:3400, hostb:3401, "
 "hostb:3402, hostc:4500, hostc:4501, hostc:4502. The configuration options "
 "allows for multiple nodes on the same host to be pinged."
-msgstr "<emphasis role=\"bold\">port_range</emphasis> bestimmt die Anzahl aufeinanderfolgender Ports, die beim ersten Erhalt der Mitgliedschaft geprüft werden, beginnend mit dem im initial_hosts-Parameter spezifizierten Port. Nehmen wir die obigen Werte für port_range und initial_hosts an, so wird der TCPPING-Layer versuchen, mit hosta:2300, hosta:2301, hosta:2302, hostb:3400, hostb:3401, hostb:3402, hostc:4500, hostc:4501, hostc:4502 zu verbinden. Die Konfigurationsoptionen erlauben es, das multiple Nodes auf demselben Host angepingt werden."
+msgstr "<emphasis role=\"bold\">port_range</emphasis> bestimmt die Anzahl aufeinanderfolgender Ports, die beim Erhalt der Initial-Mitgliedschaft geprüft werden, beginnend mit dem im initial_hosts-Parameter spezifizierten Port. Nehmen wir die obigen Werte für port_range und initial_hosts an, so wird der TCPPING-Layer versuchen, mit hosta:2300, hosta:2301, hosta:2302, hostb:3400, hostb:3401, hostb:3402, hostc:4500, hostc:4501, hostc:4502 zu verbinden. Die Konfigurationsoptionen erlauben es, dass multiple Nodes auf demselben Host angepingt werden."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:381
@@ -1283,7 +1281,7 @@
 "the load balancer and client interceptors know to avoid the dead node. The "
 "failure detection protocols are configured as sub-elements in the JGroups "
 "MBean <literal>Config</literal> element."
-msgstr "Die Protokolle zur Fehlerermittlung werden zum Auffinden ausgefallener Nodes verwendet. Sobald ein ausgefallener Node ermittelt wurde, kann eine Phase zur Überprüfung des verdächtigten Nodes stattfinden. Gild der Node danach immer noch als ausgefallen, dann wird anschließend der Cluster aktualisiert, so dass Lastverteiler und Client-Interzeptoren den ausgefallenen Node meiden. Die Protokolle zur Fehlerermittlung sind als Unterelemente im JGroups MBean <literal>Config</literal>-Element konfiguriert."
+msgstr "Die Protokolle zur Fehlerermittlung werden zum Auffinden ausgefallener Nodes verwendet. Sobald ein ausgefallener Node ermittelt wurde, kann eine Phase zur Überprüfung des verdächtigten Nodes stattfinden. Gilt der Node danach immer noch als ausgefallen, dann wird anschließend der Cluster aktualisiert, so dass Lastverteiler und Client-Interzeptoren den ausgefallenen Node meiden. Die Protokolle zur Fehlerermittlung sind als Unterelemente im JGroups MBean <literal>Config</literal>-Element konfiguriert."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:425
@@ -1361,7 +1359,7 @@
 "through the discovery process. JGroups allows to configure itself such that "
 "shunning leads to automatic rejoins and state transfer, which is the default "
 "behaivour within JBoss Application Server."
-msgstr "<emphasis role=\"bold\">shun</emphasis> bestimmt, ob ein ausgefallener Node gemieden wird. Wird dieser Node einmal gemieden, so wird er vom Cluster ausgeschlossen, selbst wenn er später wieder funktioniert. Der ausgeschlossene Node wird erst durch den Discovery-Prozess wieder Teil des Clusters. JGroups erlaubt eine Konfiguration derart, dass der Ausschluss eines Nodes automatisch zum Wiedereintritt und Statustransfer führt, was das standardmäßige Verhalten im JBoss Anwendungsserver ist."
+msgstr "<emphasis role=\"bold\">shun</emphasis> bestimmt, ob ein ausgefallener Node gemieden wird. Wird dieser Node einmal gemieden, so wird er vom Cluster ausgeschlossen, selbst wenn er später wieder funktioniert. Der ausgeschlossene Node wird erst durch den Discovery-Prozess wieder Teil des Clusters. JGroups erlaubt eine Konfiguration derart, dass der Ausschluss eines Nodes automatisch zum Wiedereintritt und Statustransfer führt, was das standardmäßige Verhalten im JBoss Application Server ist."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:450
@@ -1437,7 +1435,7 @@
 "the cluster. The suspected member is dropped from the cluster group if "
 "confirmed to be dead. The aim of this protocol is to minimize false "
 "suspicions. Here's an example."
-msgstr "Dieses Protokoll überprüft, ob ein verdächtigtes Mitglied tatsächlich ausgefallen ist, indem dieses Mitglied noch einmal angepingt wird. Diese Verifizierung erfolgt durch den Koordinator des Clusters. Falls sich der Ausfall des verdächtigten Mitglieds bestätigt, so wird er aus der Clustergruppe verwiesen. Der Zweck dieses Protokolls besteht in der Verringerung von falschen Verdächtigungen. Im Folgenden sehen Sie ein Beispiel:"
+msgstr "Dieses Protokoll überprüft, ob ein verdächtigtes Mitglied tatsächlich ausgefallen ist, indem dieses Mitglied noch einmal angepingt wird. Diese Verifizierung erfolgt durch den Koordinator des Clusters. Falls sich der Ausfall des verdächtigten Mitglieds bestätigt, so wird er der Cluster-Gruppe verwiesen. Der Zweck dieses Protokolls besteht in der Verringerung von falschen Verdächtigungen. Im Folgenden sehen Sie ein Beispiel:"
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:482
@@ -1492,7 +1490,7 @@
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:510
 #, no-c-format
 msgid "An overloaded machine might be slow in sending are-you-alive responses."
-msgstr "Eine überlastete Machine sendet die \"are-you-alive\"-Antworten ggf. nur langsam."
+msgstr "Eine überlastete Maschine sendet die \"are-you-alive\"-Antworten ggf. nur langsam."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:515
@@ -1512,7 +1510,7 @@
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:525
 #, no-c-format
 msgid "High timeouts will not detect and remove crashed members for some time."
-msgstr "Hohe Timeout-Werte führt dazu, dass ausgefallene Mitglieder für eine gewisse Zeit nicht aufgespürt und entfernt werden."
+msgstr "Hohe Timeout-Werte führen dazu, dass ausgefallene Mitglieder für eine gewisse Zeit nicht aufgespürt und entfernt werden."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:532
@@ -1588,7 +1586,7 @@
 "message if the socket was closed abnormally. However, in the case of a "
 "crashed switch or host, FD will make sure the socket is eventually closed "
 "and the suspect message generated. Example:"
-msgstr "Die zweite Lösung besteht in der Kombination von FD_SOCK und FD; der Timout in FD kann so eingestellt werden, dass dieser sehr viel niedriger ist als der TCP-Timeout, und diese Einstellung kann individuell für jeden Prozess vorgenommen werden. FD_SOCK generiert bereits eine Verdachtsnachricht, wenn der Socket nicht regulär beendet worden ist. FD wird im Falle eines gecrashten Switch oder Host jedoch sicherstellen, dass der Socket letztlich beendet wird und die Verdachtsnachricht generiert wird. Ein Beispiel:"
+msgstr "Die zweite Lösung besteht in der Kombination von FD_SOCK und FD. Der Timout in FD kann so eingestellt werden, dass dieser sehr viel niedriger ist als der TCP-Timeout, und diese Einstellung kann individuell für jeden Prozess vorgenommen werden. FD_SOCK generiert bereits eine Verdachtsnachricht, wenn der Socket nicht regulär beendet worden ist. FD wird im Falle eines gecrashten Switch oder Host jedoch sicherstellen, dass der Socket schließlich beendet wird und die Verdachtsnachricht generiert wird. Ein Beispiel:"
 
 #. Tag: programlisting
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:584
@@ -1624,7 +1622,7 @@
 "A combination of FD and FD_SOCK provides a solid failure detection layer and "
 "for this reason, such technique is used accross JGroups configurations "
 "included within JBoss Application Server."
-msgstr "Die Kombination von FD und FD_SOCK bietet eine solide Fehlerermittlungsschicht, weshalb diese Technik über alle JGroups Konfigurationen im JBoss Anwendungsserver eingesetzt wird."
+msgstr "Die Kombination von FD und FD_SOCK bietet eine solide Fehlerermittlungsschicht, weshalb diese Technik über alle JGroups Konfigurationen hinweg im JBoss Application Server eingesetzt wird."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:598
@@ -1699,8 +1697,8 @@
 "the first time, and the second time it waits for 200 ms before resending, "
 "and so on."
 msgstr ""
-"<emphasis role=\"bold\">timeout</emphasis> legt (in Millisekunden) den "
-"Timeout für die erneute Übertragung fest. Wenn zum Beispiel der Timeout "
+"<emphasis role=\"bold\">timeout</emphasis> legt den "
+"Timeout für die erneute Übertragung fest (in Millisekunden). Wenn zum Beispiel der Timeout "
 "\"100,200,400,800\" lautet, so verschickt der Sender bei Nichterhalten einer "
 "ACK die Nachricht nach 100 ms zum ersten Mal erneut. Beim zweiten Mal wartet "
 "er 200 ms bis zum erneuten Senden, usw."
@@ -1766,10 +1764,7 @@
 "<emphasis role=\"bold\">retransmit_timeout</emphasis> specifies the "
 "retransmission timeout (in milliseconds). It is the same as the "
 "<literal>timeout</literal> attribute in the UNICAST protocol."
-msgstr ""
-"<emphasis role=\"bold\">retransmit_timeout</emphasis> legt (in "
-"Millisekunden) den Timeout für die erneute Übertragung fest. Es ist dasselbe "
-"wie das <literal>timeout</literal>-Attribut im UNICAST-Protokoll."
+msgstr "<emphasis role=\"bold\">retransmit_timeout</emphasis> legt den Timeout für die erneute Übertragung fest (in Millisekunden). Es ist dasselbe wie das <literal>timeout</literal>-Attribut im UNICAST-Protokoll."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:644
@@ -1783,7 +1778,7 @@
 "<emphasis role=\"bold\">use_mcast_xmit</emphasis> bestimmt, ob der Sender "
 "die erneute Ãœbertragung an den gesamten Cluster schickt statt nur an den "
 "anfragenden Node. Dies ist hilfreich damit – falls der Sender das Paket "
-"verliert – nicht für jeden Node erneut Übertragen werden muss."
+"verliert – nicht für jeden Node erneut übertragen werden muss."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:650
@@ -1899,7 +1894,7 @@
 msgstr ""
 "<emphasis role=\"bold\">join_timeout</emphasis> legt die maximale Anzahl von "
 "Millisekunden fest, die bei der JOIN-Anfrage eines neuen Nodes gewartet "
-"wird. Anschließend folgt ein erneuter Versuch."
+"wird. Anschließend erfolgt ein erneuter Versuch."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:695
@@ -1930,7 +1925,7 @@
 "itself if it receives a cluster view that it is not a member node."
 msgstr ""
 "<emphasis role=\"bold\">shun</emphasis> legt fest, ob ein Node sich selbst "
-"meiden sollte, falls er eine Cluster-Darstellung erhält, die kein Mitglieds-Node ist."
+"meiden sollte, falls er eine Cluster-Darstellung erhält, in der er kein Mitglieds-Node ist."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:707
@@ -1950,7 +1945,7 @@
 "JOIN or LEAVE request arriving at the same time are bundled and handled "
 "together at the same time, only sending out 1 new view / bundle. This is is "
 "more efficient than handling each request separately."
-msgstr "<emphasis role=\"bold\">view_bundling</emphasis> legt fest, ob mehrere, gleichzeitig eingehende JOIN- oder LEAVE-Anfragen gebündelt und gleichzeitig zusammen gehandhabt werden, und nur 1 neue View/Gruppe versendet wird. Dies ist effizienter, als jede Anfrage einzeln zu handhaben."
+msgstr "<emphasis role=\"bold\">view_bundling</emphasis> legt fest, ob mehrere, gleichzeitig eingehende JOIN- oder LEAVE-Anfragen gebündelt und gleichzeitig zusammen gehandhabt werden, und nur 1 neue Ansicht versendet wird. Dies ist effizienter, als jede Anfrage einzeln zu handhaben."
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:720
@@ -1982,7 +1977,7 @@
 "Node überfordern und zum Verlust von Paketen führen, die dann erneut "
 "übertragen werden müssen. In JGroups ist die Flussregelung mittels eines auf "
 "\"Guthaben\" basierenden Systems implementiert (ein so genanntes \"credit-"
-"based system\"). Sender- und Empfänger-Nodes besitzen zu Beginn diesselbe "
+"based system\"). Sender- und Empfänger-Nodes besitzen zu Beginn dieselbe "
 "Guthabenmenge (Bytes). Der Sender subtrahiert Guthaben je nach der Byte-Zahl "
 "der von ihm verschickten Nachrichten. Der Empfänger addiert Guthaben je nach "
 "der Byte-Zahl der von ihm erhaltenen Nachrichten. Wenn das Guthaben des "
@@ -2025,7 +2020,7 @@
 msgstr ""
 "<emphasis role=\"bold\">max_credits</emphasis> legt die maximale Höhe des "
 "Guthabens (in Bytes) fest. Dieser Wert sollte niedriger sein als der JVM "
-"Heap-Speicher (d.h. der \"Heap Size\")."
+"Heap-Speicher (d. h. der \"Heap Size\")."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:742
@@ -2152,7 +2147,7 @@
 "the example above, if there was something about the application that would "
 "naturally cause A to slow down its rate of sending because D wasn't keeping "
 "up, then FC would not be needed."
-msgstr "Das hängt davon ab, wie die Anwendung den JGroups Channel verwendet. Wenn es – bezogen auf das obige Beispiel – in der Anwendung etwas gibt, dass die Sendegeschwindigkeit von A verringern könnte, weil D nicht mithalten konnte, dann besteht für FC keine Notwendigkeit."
+msgstr "Das hängt davon ab, wie die Anwendung den JGroups Channel verwendet. Wenn es – bezogen auf das obige Beispiel – in der Anwendung etwas gibt, das die Sendegeschwindigkeit von A verringern könnte, weil D nicht mithalten konnte, dann besteht für FC keine Notwendigkeit."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:783
@@ -2164,7 +2159,7 @@
 "members of the group. In that kind of application, the threads on A that are "
 "making calls would block waiting for responses from D, thus naturally "
 "slowing the overall rate of calls."
-msgstr "Ein gutes Beispiel für eine derartige Anwendung ist eine, die synchrone Gruppen-RPC-Aufrufe tätigt (in der Regel mittels eines JGroups RpcDispatchers). Unter synchron verstehen wir, dass der aufrufende Thread blockiert, während er auf Antworten von allen Mitgliedern der Gruppe wartet. In dieser Art von Applikation würden die Threads auf A, welche die Aufrufe tätigen, blockieren, während sie auf Antwort von D warten, und somit natürlich insgesamt die Aufrufrate verlangsamen."
+msgstr "Ein gutes Beispiel für eine derartige Anwendung ist eine, die synchrone Gruppen-RPC-Aufrufe tätigt (in der Regel mittels eines JGroups RpcDispatchers). Unter synchron verstehen wir, dass der aufrufende Thread blockiert, während er auf Antworten von allen Mitgliedern der Gruppe wartet. In dieser Art von Applikation würden die Threads auf A, welche Aufrufe tätigen, blockieren, während sie auf Antwort von D warten, und somit natürlich insgesamt die Aufrufrate verlangsamen."
 
 #. Tag: para
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:786
@@ -2197,7 +2192,7 @@
 "related to data gravitation that go to all members, but in a properly "
 "engineered buddy replication use case these should be infrequent. But if you "
 "remove FC be sure to load test your application.)"
-msgstr "Ein weiterer Fall, in dem FC ggf. nicht benötigt wird, ist ein vom JBoss Cache verwendeter Channel, der für \"Buddy Replikation\" konfiguriert ist mit einem einzigen \"Buddy\". Solch ein Channel verhält sich in vielerlei Hinsicht wie ein Cluster mit zwei Nodes, wo Nachrichten nur mit einem anderen Node ausgetauscht werden, dem Buddy. (Es gibt u. U. andere Nachrichten bezüglich Datengravitation, die an alle Mitglieder gesendet werden, aber in einem sauber entwickelten Anwendungsfall für Buddy-Replikation sollten diese selten vorkommen. Wenn Sie jedoch FC entfernen, vergessen Sie nicht, einen Lasttest für Ihre Anwendung durchzuführen.)"
+msgstr "Ein weiterer Fall, in dem FC ggf. nicht benötigt wird, ist ein vom JBoss Cache verwendeter Channel, der für \"Buddy Replikation\" konfiguriert ist mit einem einzigen \"Buddy\". Solch ein Channel verhält sich in vielerlei Hinsicht wie ein Cluster mit zwei Nodes, in dem Nachrichten nur mit einem anderen Node ausgetauscht werden, dem Buddy. (Es gibt u. U. andere Nachrichten bezüglich Datengravitation, die an alle Mitglieder gesendet werden, aber in einem sauber entwickelten Anwendungsfall für Buddy-Replikation sollte dies selten vorkommen. Wenn Sie jedoch FC entfernen, vergessen Sie nicht, einen Lasttest für Ihre Anwendung durchzuführen.)"
 
 #. Tag: title
 #: Clustering_Guide_JBoss_Cache_JGroups.xml:802
@@ -2268,7 +2263,7 @@
 "attribute. Here is an example configuration."
 msgstr ""
 "Der Statustransferdienst überträgt den Status von einem bestehenden Node "
-"(d.h. dem Cluster-Koordinator) auf einen neu hinzu kommenden Node. Er ist im "
+"(d. h. dem Cluster-Koordinator) auf einen neu hinzu kommenden Node. Er ist im "
 "<literal>pbcast.STATE_TRANSFER</literal> -Unterelement unter dem JGroups "
 "<literal>Config</literal>-Element konfiguriert. Er besitzt keine "
 "konfigurierbaren Attribute. Nachfolgend sehen Sie eine Beispielkonfiguration:"

Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JMS.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JMS.po	2009-04-21 07:06:05 UTC (rev 87607)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/de-DE/Clustering_Guide_JMS.po	2009-04-21 07:12:18 UTC (rev 87608)
@@ -9,7 +9,7 @@
 "Project-Id-Version: Clustering_Guide_JMS\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2009-01-20 02:37+0000\n"
-"PO-Revision-Date: 2009-03-02 17:04+1000\n"
+"PO-Revision-Date: 2009-04-21 15:28+1000\n"
 "Last-Translator: Hedda Peters <hpeters at redhat.com>\n"
 "Language-Team: \n"
 "MIME-Version: 1.0\n"
@@ -81,7 +81,7 @@
 "node."
 msgstr ""
 "Der JBoss HA-JMS-Dienst (d. h. Message Queues, Topics und unterstützende Dienste) wird zu jedem Zeitpunkt stets nur auf einem einzelnen Node (d. h. dem Master Node) im Cluster ausgeführt. Falls dieser Node ausfällt, wählt der Cluster "
-"einfach einen anderen Node aus, auf dem der JMS-Dienst ausgeführt wird (Failover), und die Queues, Topics und unterstützende Dienste werden auf jenem Server deployt. Diese Konfiguration bietet Redundanz gegen Serverausfälle, senkt jedoch nicht die Arbeitsbelastung am JMS-Server-Node."
+"einfach einen anderen Node aus, auf dem der JMS-Dienst ausgeführt wird (Failover), und die Queues, Topics und unterstützenden Dienste werden auf jenem Server deployt. Diese Konfiguration bietet Redundanz gegen Serverausfälle, senkt jedoch nicht die Arbeitsbelastung am JMS-Server-Node."
 
 #. Tag: para
 #: Clustering_Guide_JMS.xml:28
@@ -166,7 +166,7 @@
 msgstr ""
 "Ersetzen Sie die <literal>hsqldb-jdbc2-service.xml</literal>-Datei "
 "im <literal>server/all/deploy-hasingleton/jms</literal>-Verzeichnis mit einer "
-"speziell auf Ihre Bedürfnisse abgestimmten. Wenn Sie zum Beispiel MySQL "
+"speziell auf Ihre Bedürfnisse abgestimmten Datei. Wenn Sie zum Beispiel MySQL "
 "verwenden, so heißt die Datei <literal>mysql-jdbc2-service.xml</literal>. "
 "Die Konfigurationsdateien für eine Reihe von RDBMS sind mit der JBoss AS-Distribution gebündelt. Sie finden diese unter <literal>docs/examples/jms</literal>."
 
@@ -685,7 +685,7 @@
 "Während HA-JMS Queues und Topics jeweils nur an einem einzelnen Node "
 "ausgeführt werden, können MDBs an mehreren Nodes Nachrichten vom HA-JMS "
 "Master Node empfangen und bearbeiten. Die zweifelhaften Queues und Topics "
-"resultieren im lastverteilten Verhalten der MDBs. Um die Lastverteilung für "
+"führen zum lastverteilten Verhalten der MDBs. Um die Lastverteilung für "
 "MDBs zu aktivieren, können Sie einen Empfänger (\"Receiver\") für die Queue bestimmen. Der "
 "Empfänger protokolliert, welcher Node auf Nachricht wartet und in welcher "
 "Reihenfolge Nachrichten bearbeitet werden sollten. JBoss bietet drei "