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

Thu Jul 24 09:33:21 EDT 2008

Author: jdimanos at jboss.com
Date: 2008-07-24 09:33:21 -0400 (Thu, 24 Jul 2008)
New Revision: 76174

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

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

--- projects/docs/enterprise/4.3/Transactions/Programmers_Guide/de-DE/Chapter_02.po	2008-07-24 13:07:07 UTC (rev 76173)
+++ projects/docs/enterprise/4.3/Transactions/Programmers_Guide/de-DE/Chapter_02.po	2008-07-24 13:33:21 UTC (rev 76174)
@@ -8,7 +8,7 @@
 "Project-Id-Version: Chapter_02\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2008-06-05 22:51+0000\n"
-"PO-Revision-Date: 2008-07-21 07:14+1000\n"
+"PO-Revision-Date: 2008-07-24 23:32+1000\n"
 "Last-Translator: Jasna Dimanoski <jdimanos at redhat.com>\n"
 "Language-Team:  <de at li.org>\n"
 "MIME-Version: 1.0\n"
@@ -1180,6 +1180,8 @@
 "the object stores available in <emphasis>TxCore</emphasis> can be found in "
 "the Appendix."
 msgstr ""
+"Nebenläufigkeitskontrollinformationen innerhalb von <emphasis>TxCore</emphasis> werden durch Sperren gewartet. Zwischen Objekten in verschiedenen Prozessen geteilte Sperren können innerhalb eines Sperrspeichers aufbewahrt werden, ähnlich wie in der zuvor vorgestellten Objektspeichereinrichtung. Der mit "
+"<emphasis>TxCore</emphasis> gelieferte Sperrspeicher besitzt mit Absicht ein relativ eingeschränktes Interface, so dass er auf vielfältige Weise implementiert werden kann. Zum Beispiel werden Sperrspeicher im geteilten Speicher implementiert; im Unix-Dateisystem (in mehreren verschiedenen Formen); und als per Remote zugänglicher Speicher. Weitere Informationen zu verfügbaren Objektspeichern in <emphasis>TxCore</emphasis> finden Sie im Anhang (Appendix)."
 
 #. Tag: para
 #: Chapter_02.xml:211
@@ -1218,7 +1220,7 @@
 #: Chapter_02.xml:216
 #, no-c-format
 msgid "Selecting a lock store implementation"
-msgstr "Auswahl einer Sperrspeicher Implementierung (\"lock store\")"
+msgstr "Auswahl einer Sperrspeicher-Implementierung (\"lock store\")"
 
 #. Tag: para
 #: Chapter_02.xml:218
@@ -1235,6 +1237,8 @@
 "lockStoreType</literal> property variable. Currently this can have one of "
 "the following values:"
 msgstr ""
+"<emphasis>TxCore</emphasis> bietet Support für mehrere verschiedene Objektspeicher-Implementierungen. Falls das verwendete Objektmodell SINGLE ist, so wird zur Wartung von Sperren kein Sperrspeicher benötigt, da Informationen über das Objekt nicht exportiert werden. Wird jedoch das MULTIPLE-Modell verwendet kann es sein, das verschiedene Run-time Umgebungen (Prozesse, Java Virtual Machines) sich die Nebenläufigkeitskontrollinformationen teilen müssen. Der Implementierungstyp von zu verwendendem Sperrspeicher kann für alle Objekte innerhalb einer bestimmten Ausführungsumgebung mittels <literal>com.arjuna.ats.txoj.lockstore."
+"lockStoreType</literal>-Property Variablen festgelegt werden. Derzeit sind folgende Werte möglich:"
 
 #. Tag: term
 #: Chapter_02.xml:222
@@ -1347,6 +1351,8 @@
 "be saved if the object is recoverable. In a similar fashion, successful lock "
 "acquisition causes <command>activate</command> to be invoked."
 msgstr ""
+"Die <classname>LockManager</classname>-Klasse ist primär dafür verantwortlich Anfragen nach einer Sperreinstellung für ein Objekt oder  dem Lösen einer solchen Sperre zu verwalten. Da sie jedoch vom <classname>StateManager</classname> abgeleitet ist, kann sie außerdem steuern, wann einige der vererbten Einrichtungen aufgerufen werden. Zum Beispiel, wenn eine Anfrage zum Setzen einer Schreibsperre gewährt wird, ruft der "
+"<classname>LockManager</classname> \"modified\" in der direkten Annahme, dass der Aufruf zum Setzen einer Schreibsperre durch die aufrufende Operation bedeutet, dass das Objekt bearbeitet (modifiziert) werden soll. Dies wiederum kann dazu führen, dass Recovery-Informationen gespeichert werden, wenn es sich um ein wiederherstellbares Objekt handelt. Auf ähnliche Weise bewirkt eine erfolgreiche Sperre den Aufruf von <command>activate</command>."
 
 #. Tag: para
 #: Chapter_02.xml:251
@@ -1362,6 +1368,8 @@
 "extends the <command>save_state</command> and <command>restore_state</"
 "command> methods of <classname>StateManager</classname>."
 msgstr ""
+"Daher ist der <classname>LockManager</classname> direkt verantwortlich für das Aktivieren/Deaktivieren persistenter Objekte und die Registrierung von <classname>Resources</classname> zur Verwaltung der Nebenläufigkeitskontrolle. Durch Steuerung der <classname>StateManager</classname>-Klasse ist er außerdem verantwortlich für das Registrieren von <classname>Resources</classname> für persistente/wiederherstellbare Statusmanipulation und Objekt-Recovery. Der Anwendungsprogrammierer setzt einfach die entsprechenden Sperren, startet und beendet Transaktionen und erweitert die <command>save_state</command> und <command>restore_state</"
+"command>-Methoden von <classname>StateManager</classname>."
 
 #. Tag: programlisting
 #: Chapter_02.xml:253


