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

Sat Jul 19 22:20:55 EDT 2008

Author: jdimanos at jboss.com
Date: 2008-07-19 22:20:54 -0400 (Sat, 19 Jul 2008)
New Revision: 76018

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-19 21:18:57 UTC (rev 76017)
+++ projects/docs/enterprise/4.3/Transactions/Programmers_Guide/de-DE/Chapter_02.po	2008-07-20 02:20:54 UTC (rev 76018)
@@ -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-19 23:14+1000\n"
+"PO-Revision-Date: 2008-07-20 12:20+1000\n"
 "Last-Translator: Jasna Dimanoski <jdimanos at redhat.com>\n"
 "Language-Team:  <de at li.org>\n"
 "MIME-Version: 1.0\n"
@@ -1249,7 +1249,7 @@
 "This is an in-memory implementation which does not, by default, allow "
 "sharing of stored information between execution environments. The "
 "application programmer is responsible for sharing the store information."
-msgstr ""
+msgstr "Hierbei handelt es sich um eine Ilplementierung im Speicher, die nicht standardmäßig die Freigabe gespeicherter Informationen zwischen Ausführungsumgebungen gestattet. Der Anwendungsprogrammierer ist für die Freigabe der gespeicherten Informationen verantwortlich."
 
 #. Tag: term
 #: Chapter_02.xml:227
@@ -1270,6 +1270,8 @@
 "arjuna.ats.txoj.lockstore.lockStoreDir</literal> property variable "
 "accordingly, or placing the location within the <literal>CLASSPATH</literal>:"
 msgstr ""
+"Dieses ist die Standard-Implementierung und speichert die Sperrinformationen innerhalb des lokalen Dateisystems. Ausführungsumgebungen, die denselben Dateispeicher besitzen können also auch Informationen zur Nebenläufigkeitskontrolle teilen. Root des Dateisystems in das die Sperrinformationen geschrieben werden ist das <filename>LockStore</filename>-Verzeichnis innerhalb des <emphasis>TxCore</emphasis>-Installationsverzeichnisses. Dies kann zur Runtime entsprechend durch Einstellen der <literal>com."
+"arjuna.ats.txoj.lockstore.lockStoreDir</literal>-Propertyvariablen außer Kraft gesetzt werden oder aber durch Platzieren des Speicherorts im <literal>CLASSPATH</literal>:"
 
 #. Tag: command
 #: Chapter_02.xml:230
@@ -1300,13 +1302,13 @@
 "If neither of these approaches is taken, then the default location will be "
 "at the same level as the <filename>etc</filename> directory of the "
 "installation."
-msgstr ""
+msgstr "Wird keine dieser Vorgehensweisen unternommen, so ist der Standard-Speicherort auf derselben Ebene wie das <filename>etc</filename>-Verzeichnis der Installation."
 
 #. Tag: title
 #: Chapter_02.xml:245
 #, no-c-format
 msgid "LockManager"
-msgstr ""
+msgstr "LockManager"
 
 #. Tag: para
 #: Chapter_02.xml:247
@@ -1327,6 +1329,8 @@
 "the programmer. This ensures that the two-phase property can be correctly "
 "maintained."
 msgstr ""
+"Der Nebenläufigkeits-Controller wird durch den "
+"<classname>LockManager</classname> implementiert, der ein vernünftiges Standardverhalten liefert und dem Programmierer gleichzeitig gestattet dieses außer Kraft zu setzen, falls durch die bestimmte Semantik der programmierten Klasse erforderlich. Das primäre Programmierer-Interface für den Nebenläufigkeits-Controller ist via der Setlock-Operation. Standardmäßig erzwingt das <emphasis>TxCore</emphasis> Runtime-System strenges zwei-Phasen Sperren nach einem multiplen Reader, \"single writer\" Richtlinie auf einer pro Objekt Basis. Die Sperr-Erfassung obliegt der Kontrolle des Programmierers, da <classname>LockManager</classname> ebenso wenig bestimmen kann, ob eine Operation eine Lese- oder Schreibsperre benötigt, wie der <classname>StateManager</classname> bestimmen kann, ob eine Operation ein Objekt modifiziert. Die \"Lock-Release\" hingegen ist in der Regel unter Kontrolle des Systems und erfordert keine weiteren Maßnahmen seitens des Programmierers. Dies stellt !
 sicher, dass die zwei-Phasen Property korrekt gewartet werden kann."
 
 #. Tag: para
 #: Chapter_02.xml:249
@@ -1447,7 +1451,7 @@
 "of lock required (<literal>READ</literal> / <literal>WRITE</literal>), and "
 "the number of retries to acquire the lock before giving up. If a lock "
 "conflict occurs, one of the following scenarios will take place:"
-msgstr ""
+msgstr "Die <command>setlock</command>-Operation muss mit dem erforderlichen Sperr-Typ (<literal>READ</literal> / <literal>WRITE</literal>) sowie der Anzahl erneuter Versuche die Sperre  zu erwerben, ehe aufgegeben wird, parametisiert werden. Erfolgt ein Sperr-Konflikt, so kommt es zu einem der folgenden Szenarios:"
 
 #. Tag: para
 #: Chapter_02.xml:257
@@ -1458,6 +1462,8 @@
 "blocked until the lock is released, or the total timeout specified has "
 "elapsed, and in which <literal>REFUSED</literal> will be returned."
 msgstr ""
+"Ist der Wert des Neuversuchs gleich <literal>LockManager.waitTotalTimeout</"
+"literal>, so wird der Thread, der <command>setlock</command> aufgerufen hat, gesperrt, bis die Sperre aufgehoben oder der gesamte festgelegte Timeout vergangen ist, und in welchem <literal>REFUSED</literal> wiedergegeben wird."
 
 #. Tag: para
 #: Chapter_02.xml:261
@@ -1563,6 +1569,10 @@
 "definitions of the conflict operations enhanced levels of concurrency may be "
 "possible."
 msgstr ""
+"Anders als bei vielen anderen Systemen handelt es sich bei Sperren in <emphasis>TxCore</emphasis> nicht um spezielle Systemtypen. Stattdessen handelt es sich einfach um Instanzen anderer "
+"<emphasis>TxCore</emphasis>-Objekte (die Klasse <classname>Lock</classname>, die ebenfalls vom <classname>StateManager</classname> abgeleitet ist, so dass wenn nötig persistiert werden und auf einfache Weise benannt werden können). Desweiteren besitzt der <classname>LockManager</classname> mit Absicht keine Kenntnisse der Semantik der tatsächlichen Richtlinien entsprechend derer Sperranfragen gewährt werden. Solche Informationen werden durch die Instanzen der tatsächlichen <classname>Lock</classname>-Klasse gewartet, die Operationen bereitstellen (die "
+"<literal>conflictsWith</literal>-Operation) mittels derer der <classname>LockManager</classname> bestimmen kann, ob bei zwei Sperren ein Konflikt existiert oder nicht. Diese Trennung ist wichtig, da sie es dem Programmierer gestattet neue Sperrtypen aus der grundlegenden "
+"<classname>Lock</classname>-Klasse abzuleiten und entsprechende Definitionen der Konflikt-Operationen bereitzustellen, so dass verbesserte Nebenläufigkeitsebenen möglich sind."
 
 #. Tag: programlisting
 #: Chapter_02.xml:276
@@ -1631,12 +1641,14 @@
 "can be supported. The supplied <classname>Lock</classname> class supports "
 "the traditional multiple reader/single writer policy."
 msgstr ""
+"Die <classname>Lock</classname>-Klasse liefert eine <command>modifiesObject</command>-Operation, die der <classname>LockManager</classname> zur Bestimmung dazu verwendet"
+"ob die Gewährung dieser Sperranfrage einen Aufruf an \"modified\" erforderlich macht. Diese Operation wird bereitgestellt, damit auch Sperr-Modi, die über einfaches Lesen und Schreiben hinausgehen, unterstützt werden können. Die gelieferte <classname>Lock</classname>-Klasse unterstützt die traditionellen multiplen \"Reader/Single Writer\"-Richtlinien"
 
 #. Tag: title
 #: Chapter_02.xml:283
 #, no-c-format
 msgid "Object construction and destruction"
-msgstr ""
+msgstr "Objektkonstruktion und -löschung"
 
 #. Tag: para
 #: Chapter_02.xml:285
@@ -1648,7 +1660,7 @@
 "constructed. Thus <classname>LockManager</classname> provides two protected "
 "constructors for use by derived classes, each of which fulfils a distinct "
 "purpose:"
-msgstr ""
+msgstr "Wie schon erwähnt können <emphasis>TxCore</emphasis>-Objekte wiederherstellbar, wiederherstellbar und persistent oder keines von beidem sein. Zusätzlich besitzt jedes Objekt einen eindeutigen internen Namen. Diese Attribute können nur eingestellt werden, wenn das Objekt konstruiert wird. Der <classname>LockManager</classname> stellt daher zwei geschützte Konstruktoren für die Verwendung durch abgeleitete Klassen bereit, von denen jeder einen ganz bestimmten Zweck erfüllt:"
 
 #. Tag: command
 #: Chapter_02.xml:289
@@ -1662,13 +1674,13 @@
 msgid ""
 "This constructor allows the creation of new objects, that is, no prior state "
 "is assumed to exist."
-msgstr ""
+msgstr "Dieser Konstruktor gestattet die Erstellung neuer Objekte, das heißt es wird davon ausgegangen, dass kein vorheriger Status existiert."
 
 #. Tag: command
 #: Chapter_02.xml:294
 #, no-c-format
 msgid "LockManager (int ObjectType, ObjectName attr)"
-msgstr ""
+msgstr "LockManager (int ObjectType, ObjectName attr)"
 
 #. Tag: para
 #: Chapter_02.xml:295
@@ -1688,6 +1700,10 @@
 "memory (volatile) object store is used to store the state of the object "
 "between atomic actions."
 msgstr ""
+"Wie oben, gestattet dieser Konstruktor das Erstellen eines Objekts, das heißt es wird angenommen, dass kein vorheriger Status existiert. Der <literal>ObjectType</literal>-Parameter "
+"legt fest, ob ein Objekt einfach wiederherstellbar ist (angezeigt durch "
+"<literal>RECOVERABLE</literal>); wiederherstellbar und persistent (angezeigt durch <literal>ANDPERSISTENT</literal>) oder weder noch (<literal>NEITHER</literal>)."
+"Ist ein Objekt als persistent markiert, so wird der Status des Objekts in einem dieser Objektspeicher gespeichert. Der freigegebene Parameter ist nur von Bedeutung, wenn <literal>RECOVERABLE</literal>; ist <literal>attr</literal> nicht Null und das Objektmodell <literal>SINGLE</literal> (das Standardverhalten) dann wird der wiederherstellbare Status des Objekts innerhalb des Objekts selbst gewartet (d.h es besitzt keine externe Repräsentation), andernfalls wird ein \"in-memory\" (selbstlöschender) Objektspeicher zur Speicherung des Objektstatus zwischen atomischen Aktionen verwendet."
 
 #. Tag: para
 #: Chapter_02.xml:297
@@ -1699,7 +1715,7 @@
 "constructor commits or, if an enclosing action exists, when the appropriate "
 "top-level action commits. Later examples in this chapter illustrate this "
 "point further."
-msgstr ""
+msgstr "Konstruktoren für neue persistente Objekte sollten atomische Aktionen untereinander verwenden. Dies stellt sicher, dass der Status des Objekts automatisch in den Objektspeicher geschrieben wird wenn die Aktion im Konstruktor festgeschrieben wird oder, falls eine einschließende Aktion vorhanden ist, wenn die entsprechende Aktion der höchsten Ebene festgeschrieben wird. Spätere Beispiele in diesem Kapitel führen dies weiter aus."
 
 #. Tag: command
 #: Chapter_02.xml:301


