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

Sat Jul 26 08:46:25 EDT 2008

Author: jdimanos at jboss.com
Date: 2008-07-26 08:46:24 -0400 (Sat, 26 Jul 2008)
New Revision: 76245

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

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

--- projects/docs/enterprise/4.3/Transactions/Programmers_Guide/de-DE/Chapter.po	2008-07-26 06:27:23 UTC (rev 76244)
+++ projects/docs/enterprise/4.3/Transactions/Programmers_Guide/de-DE/Chapter.po	2008-07-26 12:46:24 UTC (rev 76245)
@@ -8,7 +8,7 @@
 "Project-Id-Version: Chapter\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-26 11:27+1000\n"
+"PO-Revision-Date: 2008-07-26 22:45+1000\n"
 "Last-Translator: Jasna Dimanoski <jdimanos at redhat.com>\n"
 "Language-Team:  <de at li.org>\n"
 "MIME-Version: 1.0\n"
@@ -225,7 +225,6 @@
 #. Tag: para
 #: Chapter.xml:58
 #, no-c-format
-#, fuzzy
 msgid ""
 "Objects are assumed to be of three possible flavours. They may simply be "
 "recoverable, in which case <classname>StateManager</classname> will attempt "
@@ -240,16 +239,7 @@
 "objects may possess none of these capabilities, in which case no recovery "
 "information is ever kept nor is object activation/deactivation ever "
 "automatically attempted."
-msgstr ""
-"Ein Objekt kann drei verschiedene Formen haben. Es kann einfach wiederherstellbar sein, in welchem Falle der <classname>StateManager</classname> versuchen wird, die entsprechenden Recovery-Informationen für das Objekt zu generieren und zu warten. Die Lebensdauer solcher Objekte überschreitet nicht diejenige des Anwendungsprogramms, das sie erstellt. Objekte können wiederherstellbar und persistent sein, in which case the "
-"lifetime of the object is assumed to be greater than that of the creating or "
-"accessing application, so that in addition to maintaining recovery "
-"information <classname>StateManager</classname> will attempt to "
-"automatically load (unload) any existing persistent state for the object by "
-"calling the activate (deactivate) operation at appropriate times. Finally, "
-"objects may possess none of these capabilities, in which case no recovery "
-"information is ever kept nor is object activation/deactivation ever "
-"automatically attempted."
+msgstr "Ein Objekt kann drei verschiedene Formen haben. Es kann einfach wiederherstellbar sein, in welchem Falle der <classname>StateManager</classname> versuchen wird, die entsprechenden Recovery-Informationen für das Objekt zu generieren und zu warten. Die Lebensdauer solcher Objekte überschreitet nicht diejenige des Anwendungsprogramms, das sie erstellt. Objekte können wiederherstellbar und persistent sein, in welchem Fall die Lebensdauer des Objekts als größer als die der erstellenden oder zugreifenden Anwendung angenommen wird, so dass neben der Wartung der Recovery-Informationen der <classname>StateManager</classname> versucht einen eventuell vorhandenen persistenten Status für das Objekt durch Aufruf der \"activate\" (\"deactivate\") Operation zu entsprechenden Zeiten automatisch zu laden (löschen). Zu guter letzt kann das Objekt auch keine dieser Fähigkeiten besitzen, in welchem Fall keine Recovery-Informationen aufbewahrt werden und die Objektaktivierung bz!
 w. -deaktivierung nie automatisch versucht wird. "
 
 #. Tag: para
 #: Chapter.xml:61
@@ -340,6 +330,8 @@
 "none of these capabilities, in which case no recovery information is ever "
 "kept nor is object activation/deactivation ever automatically attempted."
 msgstr ""
+"Ein Objekt kann drei verschiedene Formen haben. Es kann einfach <emphasis>wiederherstellbar</emphasis> sein, in welchem Falle der <classname>StateManager</classname> versuchen wird, die entsprechenden Recovery-Informationen für das Objekt zu generieren und zu warten. Die Lebensdauer solcher Objekte überschreitet nicht diejenige des Anwendungsprogramms, das sie erstellt. Objekte können <emphasis>wiederherstellbar und persistent</emphasis> sein, in welchem Fall die Lebensdauer des Objekts als größer als die der erstellenden oder zugreifenden Anwendung angenommen wird, so dass neben der Wartung der Recovery-Informationen der <classname>StateManager</classname> versucht einen eventuell vorhandenen persistenten Status für das Objekt durch Aufruf der <classname>activate</classname> (<classname>deactivate</"
+"classname>) Operation zu entsprechenden Zeiten automatisch zu laden (löschen). Zu guter letzt kann das Objekt auch keine dieser Fähigkeiten besitzen, in welchem Fall keine Recovery-Informationen aufbewahrt werden und die Objektaktivierung bzw. -deaktivierung nie automatisch versucht wird."
 
 #. Tag: para
 #: Chapter.xml:67
@@ -532,7 +524,7 @@
 "performance than when writing locks to the local disk, but objects cannot be "
 "shared between virtual machines. Importantly, it is a basic Java object with "
 "no requirements which can be affected by the SecurityManager"
-msgstr ""
+msgstr "eine rein lokale Implementierung, bei der Sperren innerhalb des Speichers der sie erstellenden virtuellen Maschine gewartet werden; diese Implemetierung bietet eine bessere Performance als wenn Sperren auf die lokale Disk geschrieben werden, aber Objekte können nicht zwischen virtuellen Maschinen geteilt werden. Wichtig ist, dass es sich um ein einfaches Java-Objekt handelt ohne durch den SecurityManager beeinflussbaren Anforderungen"
 
 #. Tag: para
 #: Chapter.xml:105
@@ -545,7 +537,7 @@
 "the <classname>Lock</classname> class it is possible for programmers to "
 "provide their own lock implementations with different lock conflict rules to "
 "enable <firstterm>type specific concurrency control</firstterm>."
-msgstr ""
+msgstr "Das primäre Programmierer-Interface zum Nebenläufigkeitskontroller ist über die \"setlock\"-Operation. Standardmäßig erzwingt das Runtime-System strikte zwei-Phasen Sperren nach einer \"multiplen Reader\", \"single Writer\" Richtlinie auf pro Objekt Basis. Wie jedoch in <xref linkend=\"figure_1\"/> gezeigt ist es für Programmierer durch Vererbung von der <classname>Lock</classname>-Klasse möglich ihre eigene Sperr-Implementierung mit anderen Sperrkonfliktregeln bereitzustellen, um <firstterm>type specific concurrency control</firstterm> zu aktivieren."
 
 #. Tag: para
 #: Chapter.xml:107
@@ -588,6 +580,8 @@
 "if the object is recoverable. In a similar fashion, successful lock "
 "acquisition causes activate to be invoked."
 msgstr ""
+"Die <classname>LockManager</classname>-Klasse ist primär verantwortlich für die Verwaltung von Anfragen zum Setzen"
+"einer Sperre oder dem Lösen einer Sperre an einem Objekt . Da sie jedoch vom <classname>StateManager</classname> abgeleitet ist, it kann sie außerdem steuern, wo einige der vererbten Facilities aufgerufen werden. Zum Beispiel geht <classname>LockManager</classname> davon aus, dass das Setzen einer Schreibsperre voraussetzt, dass die aufrufende Operation im Begriff ist das Objekt zu modifizieren. Dies wiederum kann dazu führen, dass Recovery-Information gespeichert werden, falls es sich um ein wiederherstellbares Objekt handelt. Auf ähnliche Weise führt der erfolgreiche Erwerb einer Sperre dazu, das \"activate\" aufgerufen wird."
 
 #. Tag: para
 #: Chapter.xml:113
@@ -680,6 +674,9 @@
 "if a transaction is begun within the scope of an already executing "
 "transaction it will automatically be nested."
 msgstr ""
+"Die Transaktionsprotokoll-Engine wird durch die "
+"<classname>AtomicAction</classname>-Klasse repräsentiert, die den "
+"<classname>StateManager</classname> verwendet, um ausreichende Informationen für Crash-Recovery Mechanismen zu speichern, um die Transaktion im Falle von Fehlfunktionen zu beenden. Sie besitzt Methoden zum Starten und Beenden der Transaktion sowie - für jene Situationen, in denen Programmierer ihre eigenen Ressourcen implementieren müssen - Methoden um diese bei der aktuellen Transaktion zu registrieren. Da <emphasis>TxCore</emphasis> Sub-Transaktionen unterstützt, ist eine innerhalb einer bereits vorhandenen Transaktion begonnene Transaktion automatisch verschachtelt."
 
 #. Tag: para
 #: Chapter.xml:124
@@ -689,7 +686,7 @@
 "within an application to share a transaction or execute within its own "
 "transaction. Therefore, all <emphasis>TxCore</emphasis> classes are also "
 "thread safe."
-msgstr ""
+msgstr "<emphasis>TxCore</emphasis> ist multipler Threads gewahr und erlaubt jedem Thread innerhalb einer Anwendung eine Transaktion zu teilen oder innerhalb seiner eigenen Transaktion auszuführen. Daher sind alle <emphasis>TxCore</emphasis>-Klassen auch Thread-sicher."
 
 #. Tag: title
 #: Chapter.xml:128
@@ -762,6 +759,9 @@
 "maintains the mapping between object names and locations and is described in "
 "a later chapter."
 msgstr ""
+"Das Erstellen von Bindings zu persistenten Objekten; dies könnte die Erstellung von Stub-Objekten sowie einen Aufruf an Remote-Objekte beinhalten. Im Beispiel oben an ein bestehendes, durch <literal>Name-A</"
+"literal> identifiziertes Objekt und ein neues persistentes Objekt ein erneutes Binding hergestellt wird."
+"Ein Namensgebungssystem für Remote-Objekte wartet das Mapping zwischen Objektnamen und Speicherorten und wird in einem späteren Kapitel beschrieben."
 
 #. Tag: para
 #: Chapter.xml:138
@@ -779,7 +779,7 @@
 "latest committed state from the object store. The first time a lock is "
 "acquired on an object within a transaction the object’s state is acquired, "
 "if possible, from the object store."
-msgstr ""
+msgstr "Aufrufe von Operationen: Als Teil eines bestimmten Aufrufs ist die Objektimplementierung verantwortlich dafür sicherzustellen, dass im Lese- oder Schreibmodus eine Sperre existiert (vorausgesetzt es existiert kein Sperrkonflikt) und falls nötig eine Initialisierung mit dem letzten festgeschriebenen Status aus dem Objektspeicher stattfindet. Beim erstmaligen Sperrerwerb an einem Objekt innerhalb einer Transaktion wird der Status des Objekts falls möglich aus dem Objektspeicher eingeholt."
 
 #. Tag: para
 #: Chapter.xml:140
@@ -883,6 +883,9 @@
 "action facilities is supported by <classname>AtomicAction</classname> and "
 "<classname>TopLevelTransaction</classname>."
 msgstr ""
+"Programmierer fehlertoleranter Anwendungen werden in erster Linie mit den Klassen <classname>LockManager</classname>, <classname>Lock</classname> und <classname>AtomicAction</classname> zu tun haben. Andere für Programmierer wichtige Klassen sind <classname>Uid</classname>, und <classname>ObjectState</classname>. Die meisten <emphasis>TxCore</emphasis>-Klassen sind von der Grundklasse <classname>StateManager</classname> abgeleitet, die einfachste Facilities zum managen persistenter und wiederherstellbarer Objekte bereitstellt. Diese beinhalten Support für die Aktivierung und Deaktivierung von Objekten und statusbasierte Objekt-Recovery. Die Klasse <classname>LockManager</classname> verwendet die Facilities von <classname>StateManager</classname> und "
+"<classname>Lock</classname> um die Nebenläufigkeitskontrolle bereitzustellen (zwei-Phasen Sperre in der aktuellen Implemetierung), die für die Implementierung der Serialisierbarkeits-Property von atomischen Aktionen erforderlich ist. Die Implementierung von Facilities von atomischen Aktionen wird durch <classname>AtomicAction</classname> und "
+"<classname>TopLevelTransaction</classname> unterstützt."
 
 #. Tag: para
 #: Chapter.xml:155
@@ -896,7 +899,7 @@
 "classname> uses the facilities of <classname>StateManager</classname> and "
 "provides the concurrency control required for implementing the "
 "serialisability property of atomic actions."
-msgstr ""
+msgstr "Die meisten <emphasis>TxCore</emphasis>-Systemklassen sind von der Grundklasse <classname>StateManager</classname> abgeleitet, die einfachste Facilities zum managen persistenter und wiederherstellbarer Objekte bereitstellt. Diese beinhalten Support für die Aktivierung und Deaktivierung von Objekten und statusbasierte Objekt-Recovery. Die Klasse <classname>LockManager</classname> verwendet die Facilities von <classname>StateManager</classname> und liefert die Nebenläufigkeitskontrolle, die für die Implementierung der Serialisierbarkeits-Property von atomischen Aktionen erforderlich ist."
 
 #. Tag: para
 #: Chapter.xml:157
@@ -911,6 +914,10 @@
 "O before it is modified; thus the body of op1 should contain a call to the "
 "<literal>setlock</literal> operation of the concurrency controller:"
 msgstr ""
+"Nehmen wir ein einfaches Beispiel. Gehen wir davon aus, dass <classname>Example</classname> eine benutzerdefinierte persistente Klasse entsprechend vom <classname>LockManager</classname> abgeleitet. Eine Anwendung, die eine atomische Transaktion Trans enthält, greift auf ein Objekt (genannt O) von Typ <classname>Example</"
+"classname> durch Aufruf von Operation op1 zu, welches zu Statusänderungen an O führt. "
+"Die Serialisierbarkeits-Property erfordert es, dass eine Schreibsperre an O erworben werden muss, ehe es modifiziert wird; daher sollte der Körper von op1 einen Aufruf an die "
+"<literal>setlock</literal>-Operation des Nebenläufigkeitskontrollers enthalten:"
 
 #. Tag: screen
 #: Chapter.xml:159
@@ -963,6 +970,8 @@
 "retained prior to modification) and inserting it into the "
 "<classname>RecordList</classname> of <classname>Trans</classname>."
 msgstr ""
+"Rufen Sie das <classname>StateManager</classname>-Operation \"activate\" auf, das den aktuellsten persistenten Status von O aus dem Objektspeicher lädt, falls nicht bereits der Fall. Rufen Sie dann die <classname>StateManager</classname>-Operation \"modified\" auf, die eine Instanz von entweder <classname>RecoveryRecord</classname> oder <classname>PersistenceRecord</classname> für O erstellen, je nachdem, ob O persistent war oder nicht (die Sperre ist eine <literal>WRITE</literal>-Sperre, daher muss der alte Status des Objekt vor der Modifizierung gespeichert werden) und in die "
+"<classname>RecordList</classname> von <classname>Trans</classname> eingefügt werden."
 
 #. Tag: para
 #: Chapter.xml:166


