Author: jdimanos(a)jboss.com Date: 2009-05-31 08:02:12 -0400 (Sun, 31 May 2009) New Revision: 8077 Modified: enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Transactions.po Log: update Modified: enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Transactions.po =================================================================== --- enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Transactions.po 2009-05-30 12:50:48 UTC (rev 8076) +++ enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/de-DE/Transactions.po 2009-05-31 12:02:12 UTC (rev 8077) @@ -8,7 +8,7 @@ "Project-Id-Version: Transactions\n" "Report-Msgid-Bugs-To: http://bugs.kde.org\n" "POT-Creation-Date: 2008-09-21 04:44+0000\n" -"PO-Revision-Date: 2009-05-30 22:50+1000\n" +"PO-Revision-Date: 2009-05-31 22:01+1000\n" "Last-Translator: \n" "Language-Team: <en(a)li.org&gt;\n&quot; "MIME-Version: 1.0\n" @@ -223,6 +223,12 @@ "&#8216;non-repeatable read&#8217; where one thread reads the data twice can " "produce different results. For example, if you have the following sequence," msgstr "" +"READ_COMMITTED. Daten können jederzeit gelesen werden (\"read\"), " +"solange kein Schreibvorgang (\"write\") stattfindet. Dies verhindert einen " +"\"dirty read\". Es verhindert allerdings nicht einen sogenannten " +"&#8216;non-repeatable read&#8217; bei dem ein Thread die Daten zwei Mal " +"liest und unterschiedliche Ergebnisse liefern kann. " +"Wenn Sie zum Beispiel die folgende Sequenz haben: " #. Tag: programlisting #: Transactions.xml:51 @@ -242,7 +248,7 @@ #: Transactions.xml:53 #, no-c-format msgid "where the second read in Tx1 thread will produce different result." -msgstr "wo der zweite Read im Tx1 Thread ein anderes Ergebnis liefert." +msgstr "wo der zweite \"read\" im Tx1 Thread ein anderes Ergebnis liefert." #. Tag: para #: Transactions.xml:56 @@ -257,6 +263,18 @@ "data might return different values. Note that, the write only applies " "regardless of transaction state (whether it has been committed or not)." msgstr "" +"Implementierungen verwenden in der Regel eine \"read-write\"-Sperre; " +"Lesevorgänge (\"reads\") sind erfolgreich beim Erwerb der Sperre, wenn " +"lediglich Lesevorgänge existieren, Schreibvorgänge müssen warten, " +"bis keine Leser mehr die Sperre aufrechterhalten, und Leser werden vom " +"Erwerb der Sperre blockiert, bis keine Schreiber diese mehr aufrechterhalten. " +"Lesevorgänge lösen nach Beendigung die \"read\"-Sperre, so dass ein " +"nachfolgender Lesevorgang an denselben Daten erneut eine Lesesperre " +"erwerben muss; dies führt zu nicht wiederholbaren Lesevorgängen " +"(\"nonrepeatable reads\"), wo 2 Lesevorgänge derselben Daten " +"unterschideliche Werte wiedergeben können. Beachten Sie, dass der " +"Schreibvorgang nur gilt unabhängig vom Transaktionsstatus " +"(ob festgeschrieben oder nicht)." #. Tag: para #: Transactions.xml:61 @@ -268,6 +286,13 @@ "the other transaction. Implementations typically use a read-write lock. This " "is the default isolation level used." msgstr "" +"REPEATABLE_READ. Daten können gelesen werden (\"read\"), während kein " +"Schreibvorgang (\"write\") stattfindet und umgekehrt. " +"Diese Ebene verhindert einen \"non-repeatable read\", verhindert allerdings " +"keinen sogenannten \"phantom read\", bei dem Daten von einer anderen " +"Transaktion in einen Baum eingefügt werden können. Implementierungen " +"verwenden in der Regel eine \"read-write\"-Sperre. Dies ist die standardmäßig " +"verwendete Isolationsebene." #. Tag: para #: Transactions.xml:66 @@ -278,6 +303,10 @@ "the end of the transaction. Regarded as very poor for performance and thread/" "transaction concurrency." msgstr "" +"SERIALIZABLE. Datenzugriff wird mit exklusiven Sperren synchronisiert. Nur 1 " +"Schreiber oder Leser kann die Sperre zum selben Zeitpunkt haben. Sperren " +"werden am Ende der Transaktion gelöst. Gilt als sehr unvorteilhaft für Performance " +"und Thread-/Transaktionsnebenläufigkeit." #. Tag: title #: Transactions.xml:74 @@ -301,6 +330,20 @@ "require the acquisition of a <emphasis>read lock</emphasis> on the parent " "node." msgstr "" +"Standardmäßig versucht JBoss Cache vor dem Einfügen eines neuen " +"oder dem Entfernen eines bestehenden Node in den bzw. aus dem Baum " +"eine Schreibsperre am übergeordneten Node des neuen Node zu erwerben. " +"Diese Herangehensweise behandelt untergeordnete Nodes als einen " +"integralen Teil des Status eines übergeordneten Node. Sie liefert höhere " +"Korrektheit, jedoch auf Kosten geringerer Nebenläufigkeit wenn Nodes " +"häufig hinzugefügt oder entfernt werden. " +"Für Fälle, in denen diese höhere Korrektheit nicht relevant ist, bietet " +"JBoss Cache die Konfigurationsoption " +"<literal>LockParentForChildInsertRemove</literal>. Ist diese auf " +"<literal>false</literal> eingestellt, so erfordern Einfügungen und " +"Entfernungen von untergeordneten Nodes nur den Erwerb einer " +"<emphasis>Lesesperre</emphasis> (sog. \"read lock\") am " +"übergeordneten Node." #. Tag: title #: Transactions.xml:83 @@ -320,6 +363,15 @@ "a technique called data versioning, explained here. Note that isolation " "levels (if configured) are ignored if optimistic locking is enabled." msgstr "" +"Der Grund für optimistisches Sperren ist die Verbesserung der Nebenläufigkeit. " +"Liegen viele Threads im Wettstreit um Zugriff auf den Datenbaum, so kann " +"sich das Sperreb von Teilen des Baums - zum Lesen oder Schreiben - für die " +"gesamte Dauer der Transaktion wie beim pessimistischen Sperren als " +"ineffizient erweisen. Optimistisches Sperren gestattet größere Nebenläufigkeit " +"von Threads und Transaktionen durch Verwendung einer Technik namens " +"Datenversionierung (\"data versioning\"), die hier erläutert wird. " +"Beachten Sie, dass Isolationsebenen (falls konfiguriert) ignoriert werden, " +"wenn optimistisches Sperren aktiviert ist." #. Tag: title #: Transactions.xml:88 @@ -339,6 +391,16 @@ "invocation completes. Each transaction maintains a transaction workspace, " "which contains a copy of the data used within the transaction." msgstr "" +"Optimistisches Sperren behandelt alle Methodenaufrufe als " +"transaktional<footnote><para> Wegen dieser Anforderung " +"müssen Sie stets einen Transaktionsmanager " +"konfiguriert haben, wenn Sie optimistisches Sperren " +"verwenden. </para> </footnote>. Selbst wenn Sie einen Aufruf " +"innerhalb des Geltungsbereichs einer laufenden Transaktion nicht aufrufen, " +"erstellt JBoss Cache eine implizite Transaktion und schreibt diese Transaktion " +"fest, wenn der Aufruf beendet wird. Jede Transaktion wartet einen " +"Transaktionsarbeitsbereich, der eine Kopie der innerhalb der Transaktion " +"verwendeten Daten enthält." #. Tag: para #: Transactions.xml:95 @@ -355,6 +417,17 @@ "transaction throws a <literal>RollbackException</literal> when committing " "and the commit fails." msgstr "" +"Wenn eine Transaktion zum Beispiel get(\"/a/b/c\") aufruft, so werden Nodes " +"a, b und c vom Hauptdatenbaum und in einen Arbeitsbereich kopiert. " +"Die Daten werden versioniert und alle Aufrufe in der Transaktion arbeiten an " +"der Kopie der Daten statt an den Daten selbst. Wird die Transaktion " +"festgeschrieben, so wird deren Arbeitsbereich durch Übereinstimmen der " +"Versionen wieder dem darunterliegenden Baum zugefügt. Stimmen Versionen " +"nicht überein - etwa wenn der tatsächliche Datenbaum eine höhere Version " +"als der Arbeitsbereich besitzt, vielleicht weil eine weitere Transaktion auf " +"dieselben Daten zugreift, diese verändert und festschreibt ehe die erste " +"Transaktion endet - so meldet die Transaktion bei der Festschreibung eine " +"<literal>RollbackException</literal>, und die Festschreibung schlägt fehl." #. Tag: para #: Transactions.xml:98 @@ -365,6 +438,10 @@ "a workspace, and when the transaction commits and has to merge data back " "into the tree." msgstr "" +"Optimistisches Sperren verwendet dieselben Sperren die wir oben erwähnen, " +"jedoch werden die Sperren nur für kurze Zeit gehalten - zu Beginn einer " +"Transaktion zur Schaffung eines Arbeitsbereichs und bei der Festschreibung " +"der Transaktion, wenn Daten erneut in den Baum eingefügt werden." #. Tag: para #: Transactions.xml:101 @@ -376,6 +453,13 @@ "versioned data and validating on commit, it does buy you a near-SERIALIZABLE " "degree of data integrity while maintaining a very high level of concurrency." msgstr "" +"Während also optimistisches Sperren gelegentlich fehlschlagen kann, wenn " +"Versionsvalidierungen fehlschlagen oder aufgrund des unvermeidlichen " +"Overhead und der zusätzlichen Bearbeitung der Wartung von Arbeitsbereichen, " +"versionierten Daten und Validierung bei Festschreibung etwas langsamer als " +"pessimistisches Sperren läuft, so liefert es doch einen nahezu SERIALIZABLE " +"Grad an Datenintegrität, während ein hohes Niveau an Nebenläufigkeit gewahrt " +"wird. " #. Tag: title #: Transactions.xml:107 @@ -390,6 +474,8 @@ "Optimistic locking is enabled by using the NodeLockingScheme XML attribute, " "and setting it to \"OPTIMISTIC\":" msgstr "" +"Optimistisches Sperren wird durch Verwendung des NodeLockingScheme XML-Attributs aktiviert, " +"und indem dieses auf \"OPTIMISTIC\" eingestellt wird:" #. Tag: programlisting #: Transactions.xml:108 @@ -430,6 +516,13 @@ "based asynchronous replication is used </para> </footnote> replicated after " "every change (if replication is enabled)." msgstr "" +"JBoss Cache kann so konfiguriert werden, dass es Transaktionen zur Bündelung " +"von Arbeitseinheiten verwendet, was dann als eine Einheit repliziert werden kann. " +"Alternativ - wenn Transaktionssupport deaktiviert ist - ist es gleichwertig zur " +"Einstellung von AutoCommit auf wo Änderungen potenziell <footnote><para> " +"Abhängig davon, ob Intervall-basierte asynchrone Replikation verwendet wird" +"</para> </footnote> nach jeder Änderung repliziert wird (falls Replikation " +"aktiviert ist)." #. Tag: para #: Transactions.xml:123 @@ -450,6 +543,9 @@ "register (if not already done) with the transaction manager to be notified " "when a transaction commits or is rolled back." msgstr "" +"registrieren Sie sich (falls nicht schon erfolgt) beim Transaktionsmanager " +"damit Sie beim Festschreiben oder Zurücksetzen einer Transaktion " +"benachrichtigt werden." #. Tag: para #: Transactions.xml:138 @@ -459,6 +555,10 @@ "<literal>TransactionManagerLookup</literal> which returns a <literal>javax." "transaction.TransactionManager</literal>." msgstr "" +"Um dies zu tun, muss das Cache mit einer Instanz eines " +"<literal>TransactionManagerLookup</literal> konfiguriert werden, " +"die einen <literal>javax." +"transaction.TransactionManager</literal> wiedergibt." #. Tag: para #: Transactions.xml:141 @@ -476,6 +576,17 @@ "outside a Java EE Application Server. Being a dummy, however, this is just " "for demo and testing purposes and is not recommended for production use." msgstr "" +"JBoss Cache wird mit <literal>JBossTransactionManagerLookup</literal> und " +"<literal>GenericTransactionManagerLookup</literal> geliefert. Der " +"<literal>JBossTransactionManagerLookup</literal> kann an einen " +"laufenden JBoss Application Server anbinden und einen <literal>TransactionManager</" +"literal> abrufen, während der <literal>GenericTransactionManagerLookup</literal> " +"an die beliebtesten Java EE Application Server anbinden und dieselbe Funktionalität " +"bereitstellen kann. Eine Dummy-Implementierung - " +"<literal>DummyTransactionManagerLookup</literal> - wird ebenfalls geliefert, was " +"für eigenständige JBoss Cache Anwendungen und Einheiten-Tests verwendet werden kann, " +"die außerhalb eines Java EE Application Server laufen. Ein Dummy dienst jedoch nur als " +"Demo und zu Testzwecken und wird nicht zum Produktionsgebrauch empfohlen." #. Tag: para #: Transactions.xml:144 @@ -484,6 +595,8 @@ "The implementation of the <literal>JBossTransactionManagerLookup</literal> " "is as follows:" msgstr "" +"Die Implementierung des <literal>JBossTransactionManagerLookup</literal> " +"ist wie folgt:" #. Tag: programlisting #: Transactions.xml:147 @@ -501,6 +614,17 @@ " }\n" "}" msgstr "" +"public class JBossTransactionManagerLookup implements " +"TransactionManagerLookup {\n" +"\n" +" public JBossTransactionManagerLookup() {}\n" +"\n" +" public TransactionManager getTransactionManager() throws Exception {\n" +" Object tmp=new InitialContext().lookup(\"java:/TransactionManager" +"\");\n" +" return (TransactionManager)tmp;\n" +" }\n" +"}" #. Tag: para #: Transactions.xml:148 @@ -508,7 +632,7 @@ msgid "" "The implementation looks up the JBoss Transaction Manager from JNDI and " "returns it." -msgstr "" +msgstr "Die Implementierung findet den JBoss Transaction Manager im JNDI und erwidert diesen." #. Tag: para #: Transactions.xml:151 @@ -523,6 +647,14 @@ "notified of transaction committed or aborted when it first encounters the " "transaction." msgstr "" +"Kommt ein Aufruf herein, so holt sich <literal>TreeCache</literal> die " +"aktuelle Transaktion und speichert die Modifikation als Schlüssel unter der " +"Transaktion. (Gibt es keine Transaktion, so wird die Modifikation sofort " +"angewendet und möglicherweise repliziert). So werden über den Lebenszyklus der " +"Transaktion alle Änderungen aufgezeichnet und mit der Transaktion assoziiert. " +"Auch registriert das <literal>TreeCache</literal> mit den Transaktionen, um über " +"festgeschriebene oder abgebrochene Transaktionen benachrichtigt zu werden, " +"wenn es erstmals auf die Transaktion trifft." #. Tag: para #: Transactions.xml:154 @@ -531,6 +663,8 @@ "When a transaction rolls back, we undo the changes in the cache and release " "all locks." msgstr "" +"Wir eine Transaktion zurückgesetzt, so machen wir Änderungen im Cache " +"rückgängig und lösen alle Sperren." #. Tag: para #: Transactions.xml:157 @@ -544,6 +678,15 @@ "then sends back a success message. If a node in a cluster cannot acquire all " "locks, or fails otherwise, it sends back a failure message." msgstr "" +"Wird eine Transaktion festgeschrieben, initiieren wir ein zwei-Phasen " +"Festschreibungsprotokoll<footnote><para> Nur mit synchroner Replikation " +"oder Invalidierung. " +"</para> </footnote> : In der ersten Phase wird ein alle für die aktuelle " +"Transaktion alle Änderungen enthaltendes PREPARE an sämtliche Nodes im " +"Cluster geschickt. Jeder Node erwirbt alle notwendigen Sperren, wendet die " +"Änderungen an und sendet dann eine Erfolgsmeldung zurück. " +"Kann ein Node in einem Cluster nicht alle Sperren erwerben oder schlägt er " +"auf anderen Weise fehl, so wird eine Fehlermeldung zurückgeschickt." #. Tag: para #: Transactions.xml:163 @@ -556,6 +699,13 @@ "reception of the ROLLBACK message, every node undoes the changes for the " "given transaction, and releases all locks held for the transaction." msgstr "" +"Der Koordinator des Zweiphasen-Festschreibungsprotokolls wartet " +"auf alle Antworten (oder einen Timeout, je nachdem was zuerst erfolgt). " +"Antwortet einer der Nodes im Cluster mit FAIL (oder der Timeout), so wird " +"eine Zurücksetzphase (Rollback) initiiert: Eine ROLLBACK-Nachricht wird an " +"sämtliche Nodes im Cluster. Bei Erhalt der ROLLBACK-Nachricht, macht " +"jeder Node die Änderungen für die betreffende Transaktion rückgängig und löst " +"alle für die Transaktion gehaltenen Sperren." #. Tag: para #: Transactions.xml:166 @@ -565,6 +715,10 @@ "cluster. On reception of a COMMIT message, each node applies the changes for " "the given transaction and releases all locks associated with the transaction." msgstr "" +"Sind alle Antworten OK, so wird eine COMMIT-Nachricht an alle Nodes im " +"Cluster. Bei Erhalt einer COMMIT-Nachricht wendet jeder Node die Änderungen " +"für die betreffende Transaktion an und löst alle mit der Transaktion assoziierten " +"Sperren." #. Tag: para #: Transactions.xml:169 @@ -574,12 +728,15 @@ "of a local transaction, which uniquely identifies a transaction across a " "cluster." msgstr "" +"Wenn wir von einer 'Transaktion' sprechen, so meinen wir eine allgemeingültige " +"Repräsentation einer lokalen Transaktion, die eine Transaktion über einen Cluster " +"hinweg eindeutig identifiziert." #. Tag: title #: Transactions.xml:173 #, no-c-format msgid "Example" -msgstr "" +msgstr "Beispiel" #. Tag: para #: Transactions.xml:174 @@ -588,6 +745,9 @@ "Let's look at an example of how to use JBoss Cache in a standalone (i.e. " "outside an application server) fashion with dummy transactions:" msgstr "" +"Sehen wir uns ein Beispiel an, wie JBoss Cache auf eigenständige Weise " +"(d.h. außerhalb eines Applikationsservers) mit Dummy-Transaktionen " +"verwendet wird:" #. Tag: programlisting #: Transactions.xml:177 @@ -614,6 +774,26 @@ " try { tx.rollback(); } catch(Throwable t) {}\n" "}" msgstr "" +"Properties prop = new Properties();\n" +"prop.put(Context.INITIAL_CONTEXT_FACTORY, \"org.jboss.cache.transaction." +"DummyContextFactory\");\n" +"User Transaction tx=(UserTransaction)new InitialContext(prop).lookup" +"(\"UserTransaction\");\n" +"TreeCache tree = new TreeCache();\n" +"PropertyConfigurator config = new PropertyConfigurator();\n" +"config.configure(tree, \"META-INF/replSync-service.xml\");\n" +"tree.createService(); // not necessary\n" +"tree.startService(); // kick start tree cache\n" +"\n" +"try {\n" +" tx.begin();\n" +" tree.put(\"/classes/cs-101\", \"description\", \"the basics\");\n" +" tree.put(\"/classes/cs-101\", \"teacher\", \"Ben\");\n" +" tx.commit();\n" +"}\n" +"catch(Throwable ex) {\n" +" try { tx.rollback(); } catch(Throwable t) {}\n" +"}" #. Tag: para #: Transactions.xml:178 @@ -622,6 +802,8 @@ "The first lines obtain a user transaction using the 'JEE way' via JNDI. Note " "that we could also say" msgstr "" +"Die ersten Zeilen erhalten eine Nutzertransaktion unter Verwendung des " +"'JEE way' via JNDI. Beachte Sie, dass wir auch sagen könnten " #. Tag: programlisting #: Transactions.xml:182 @@ -630,6 +812,8 @@ "UserTransaction tx = new DummyUserTransaction(DummyTransactionManager." "getInstance());" msgstr "" +"UserTransaction tx = new DummyUserTransaction(DummyTransactionManager." +"getInstance());" #. Tag: para #: Transactions.xml:184 @@ -639,6 +823,9 @@ "class and a configuration XML file (see below for a list of all " "configuration options)." msgstr "" +"Wir erstellen dann ein neues TreeCache und konfigurieren es mittels einer " +"PropertyConfigurator-Klasse und einer Konfigurations-XML-Datei (nachfolgend sehen " +"Sie eine Liste aller Konfigurationsoptionen)." #. Tag: para #: Transactions.xml:187 @@ -654,4 +841,14 @@ "commit protocol applying the modifications to all nodes in the cluster, the " "transaction is rolled back." msgstr "" +"Als nächstes starten wir das Cache. dann starten wir eine Transaktion " +"(und assoziieren sie intern mit dem aktuellen Thread). Jegliche am Cache " +"aufgerufene Methoden werden jetzt gesammelt und nur angewendet, " +"wenn die Transaktion festgeschrieben wird. Im Fall oben erstellen wir einen " +"Node \"/classes/cs-101\" und fügen dessen Map 2 Elemente hinzu. " +"Davon ausgehend, dass das Cache zur synchronen Replikation konfiguriert ist, " +"werden die Änderungen bei der Festschreibung der repliziert. Existiert in den " +"Methoden eine Ausnahme (z.B. fehlgeschlagener Sperrerwerb) oder im " +"zwei-Phasen Festschreibungsprotokoll, das die Änderungen an allen Nodes " +"im Cluster anwendet, so wird die Transaktion zurückgesetzt."