Author: mospina
Date: 2008-10-27 01:01:55 -0400 (Mon, 27 Oct 2008)
New Revision: 7016
Modified:
enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/es-ES/Transactions.po
Log:
translation in progress
Modified: enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/es-ES/Transactions.po
===================================================================
---
enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/es-ES/Transactions.po 2008-10-26
21:31:15 UTC (rev 7015)
+++
enterprise-docs/tags/JBoss_EAP_4_3/Cache_Tree_Cache_Guide/es-ES/Transactions.po 2008-10-27
05:01:55 UTC (rev 7016)
@@ -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: 2008-10-17 12:15+1000\n"
+"PO-Revision-Date: 2008-10-27 14:50+1000\n"
"Last-Translator: Angela Garcia\n"
"Language-Team: <en(a)li.org>\n"
"MIME-Version: 1.0\n"
@@ -20,13 +20,13 @@
#: Transactions.xml:5
#, no-c-format
msgid "Transactions and Concurrency"
-msgstr ""
+msgstr "Transacciones y concurrencia"
#. Tag: title
#: Transactions.xml:7
#, no-c-format
msgid "Concurrent Access"
-msgstr ""
+msgstr "Acceso concurrente"
#. Tag: para
#: Transactions.xml:8
@@ -35,13 +35,13 @@
"JBoss Cache uses a pessimistic locking scheme by default to prevent "
"concurrent access to the same data. Optimistic locking may alternatively be "
"used, and is discussed later."
-msgstr ""
+msgstr "JBoss Cache utiliza un esquema de bloqueo pesimista por defecto para
prevenir acceso concurrente a los mismo datos. Alternativamente se puede utilizar el
bloqueo optimista y lo vamos a discutir más adelante."
#. Tag: title
#: Transactions.xml:12
#, no-c-format
msgid "Locks"
-msgstr ""
+msgstr "Bloqueos"
#. Tag: para
#: Transactions.xml:13
@@ -53,6 +53,8 @@
"hold locks for \"a\", \"b\" and \"c\", we only need
to acquire a lock for \"d"
"\"."
msgstr ""
+"El bloqueo se realiza internamente, a nivel de nodo. Por ejemplo cuando queremos
acceder a \"/a/b/c\", se adquirirá un bloqueo para los nodos \"a\",
\"b\" y \"c\". Cuando la misma transacción quiere acceder a
\"/a/b/c/d\" ya que ya tenemos bloqueos para \"a\", \"b\" y
\"c\", por lo tanto sólo necesitamos adquirir un bloqueo para \"d"
+"\"."
#. Tag: para
#: Transactions.xml:16
@@ -66,7 +68,7 @@
"two-phase commit protocol (see below) across the cluster, the "
"<literal>GlobalTransaction</literal> uniquely identifies the unit of
work "
"across a cluster."
-msgstr ""
+msgstr "Los propietarios de los bloqueos pueden ser las transacciones (una llamada
se realiza dentro del ámbito de una transacción existente) o también pueden ser hilos (no
hay transacciones asociadas con la llamada). Sin importar cual sea, una transacción o un
hilo es transformado internamente en una instancia de
<literal>GlobalTransaction</literal>, el cual se utiliza como un ID único
global para modificaciones a través del clúster. Por ejemplo, cuando ejecutamos a un
protocolo para guardar los cambios en dos fases (vea c continuación), el
<literal>GlobalTransaction</literal> identifica de manera única la unidad de
trabajo a través de un clúster. "
#. Tag: para
#: Transactions.xml:19
@@ -79,7 +81,7 @@
"has to wait until all read locks have been released. When scheduled "
"concurrently, write locks always have precedence over read locks. Note that "
"(if enabled) read locks can be upgraded to write locks."
-msgstr ""
+msgstr "Los bloqueos pueden ser de lectura o de escritura. Los bloqueos de escritura
serializan el acceso de escritura y de lectura en tanto que los bloqueos de sólo lectura
solamente serializan el acceso de lectura. Cuando un bloqueo de lectura se mantiene, no se
pueden adquirir otros bloqueos de lectura o de escritura. Cuando se mantiene un bloqueo de
lectura, los otros pueden adquirir bloqueos de lectura. Sin embargo, para adquirir
bloqueos de escritura, tiene que esperar hasta que todos los bloqueos de lectura hayan
sido liberados. Cuando se programan de manera concurrente, los bloqueos de escritura
siempre tienen precedencia sobre los bloqueos de lectura. Obsreve que los bloqueos de
lectura se pueden actualizar a bloqueos de escritura (si se habilita). "
#. Tag: para
#: Transactions.xml:22
@@ -94,12 +96,15 @@
"lock for \"/a/b/n2\". This allows for more concurrency in accessing the
"
"cache."
msgstr ""
+"El utilizar bloqueos de lectura-escritura ayuda en el siguiente escenario:
considere un árbol con las entradas \"/a/b/n1\" y \"/a/b/n2\". Con
bloqueos de escritura, cuando Tx1 accede a \"/"
+"a/b/n1\", Tx2 no puede acceder a \"/a/b/n2\" hasta que Tx1 haya
completado y liberado sus bloqueos. Sin embargo, esto es posible con bloqueos de
lectura-escritura ya que Tx1 "
+"adquiere bloqueos de lectura para \"/a/b\" y un bloqueo de
lectura-escritura para \"/a/b/n1\". Entonces Tx2 puede adquirir bloqueos de
lectura para \"/a/b\" también además de un bloqueo de lectura-escritura para
\"/a/b/n2\". Esto permite mayor concurrencia al acceder el caché. "
#. Tag: title
#: Transactions.xml:28
#, no-c-format
msgid "Pessimistic locking"
-msgstr ""
+msgstr "Bloqueo pesimista"
#. Tag: para
#: Transactions.xml:29
@@ -108,13 +113,13 @@
"By default, JBoss Cache uses pessimistic locking. Locking is not exposed "
"directly to user. Instead, a transaction isolation level which provides "
"different locking behaviour is configurable."
-msgstr ""
+msgstr "Por defecto, JBoss Cache utiliza el bloqueo pesimista. El bloqueo no se
expone directamente al usuario. En su lugar es configurable un nivel de aislamiento de
transacción, el cual proporciona un comportamiento de bloqueo diferente. "
#. Tag: title
#: Transactions.xml:33
#, no-c-format
msgid "Isolation levels"
-msgstr ""
+msgstr "Niveles de aislamiento"
#. Tag: para
#: Transactions.xml:34
@@ -125,6 +130,8 @@
"isolation level of NONE, READ_UNCOMMITTED, READ_COMMITTED, REPEATABLE_READ, "
"or SERIALIZABLE. REPEATABLE_READ is the default isolation level used."
msgstr ""
+"JBoss Cache soporta los siguientes niveles de aislamiento de transacciones, análogo
a los niveles de aislamiento ACID de la base de datos. Un usuario puede configurar un
nivel de aislamiento que abarca una instancia de NONE, READ_UNCOMMITTED, READ_COMMITTED,
REPEATABLE_READ, "
+"o SERIALIZABLE. REPEATABLE_READ es el nivel de aislamiento predeterminado."
#. Tag: para
#: Transactions.xml:39
@@ -133,7 +140,7 @@
"NONE. No transaction support is needed. There is no locking at this level,
e."
"g., users will have to manage the data integrity. Implementations use no "
"locks."
-msgstr ""
+msgstr "NONE. No se necesita soporte de transacciones. No hay bloqueo a este nivel,
por ejemplo, los usuarios tendrán que administrar la integridad de los datos. Las
implementacione no utilizan bloqueos."
#. Tag: para
#: Transactions.xml:44
@@ -150,6 +157,13 @@
"Implementations typically use an exclusive lock for writes while reads don't
"
"need to acquire a lock."
msgstr ""
+"READ_UNCOMMITTED. Los datos se pueden leer en cualquier momento mientras que las
operaciones de escritura son "
+"exclusivas. Observe que este nivel no previene la llamada \"lectura
sucia\" "
+"en donde los datos modificados en Tx1 pueden ser leidos en Tx2 antes de que Tx1
guarde los cambios. En otras palabras, si tiene la siguiente secuencia,
<programlisting>\n"
+" Tx1 Tx2\n"
+" W\n"
+" R\n"
+"</programlisting> utilizando este nivel de aislamiento Tx2 no realizará la
lectura. Las implementaciones usualmente utilizan un bloqueo exclusivo para escrituras
mientras que las lecturas no necesitan adquirir un bloqueo."
#. Tag: para
#: Transactions.xml:50
@@ -159,7 +173,7 @@
"level prevents the dirty read. But it doesn’t prevent the so-called
"
"‘non-repeatable read’ where one thread reads the data twice can
"
"produce different results. For example, if you have the following sequence,"
-msgstr ""
+msgstr "READ_COMMITTED. Los datos se pueden leer en cualquier momento en tanto no
hayan escrituras. Este nivel previene la lectura sucia. Pero no previene la llamada
lectura no-repetible; en donde un hilo lee los datos dos veces puede producir resultados
diferentes. Por ejemplo, si tiene la siguiente secuencia:"
#. Tag: programlisting
#: Transactions.xml:51
@@ -179,7 +193,7 @@
#: Transactions.xml:53
#, no-c-format
msgid "where the second read in Tx1 thread will produce different result."
-msgstr ""
+msgstr "en donde la segunda lectura en el hilo Tx1 producirá un resultado diferente.
"
#. Tag: para
#: Transactions.xml:56
@@ -193,7 +207,7 @@
"a read-lock; this leads to nonrepeatable reads, where 2 reads of the same "
"data might return different values. Note that, the write only applies "
"regardless of transaction state (whether it has been committed or not)."
-msgstr ""
+msgstr "Las implementaciones usualmente utilizan un bloquoe de lectura-escritura;
las lecturas tienen éxito al adquiri el bloqueo cuando sólo hay lecturas, las escrituras
tienen que esperar hasta que no hayan más lectores con bloqueos y los lectores son
bloqueados adquiriendo el bloqueo hasta que no hay más escritores con bloqueos. Las
lecturas usualmente liberan el bloqueo de lectura cuando han terminado de manera que una
lectura subsecuente en los mismos datos tiene que volver a adquirir un bloqueo de lectura,
esto conlleva a lecturas no repetible, en donde dos lecturas de los mismo datos pueden
retornar valores diferentes. Observe que la escritura sólo aplica sin importar el estado
de la transacción (ya sea que se hayan guardado los cambios o no). "
#. Tag: para
#: Transactions.xml:61
@@ -204,7 +218,7 @@
"called \"phantom read\" where new data can be inserted into the tree from
"
"the other transaction. Implementations typically use a read-write lock. This
"
"is the default isolation level used."
-msgstr ""
+msgstr "REPEATABLE_READ. Los datos se pueden leer en tanto no haya escrituras y
viceversa. Este nivel previene \"lecturas no-repetibles\" pero no previene la
llamada \"lectura fantasma\" en donde se pueden insertar nuevos datos en el
árbol desde otra transacción. Las implementaciones usualmente utilizan un bloqueo de
lectura-escritura. Este es el nivel de aislamiento predeterminado."
#. Tag: para
#: Transactions.xml:66
@@ -214,13 +228,13 @@
"writer or reader can have the lock at any given time. Locks are released at "
"the end of the transaction. Regarded as very poor for performance and
thread/"
"transaction concurrency."
-msgstr ""
+msgstr "SERIALIZABLE. El acceso a los datos es sincronizado con bloqueos exclusivos.
Sólo un escritor o lector puede tener el bloqueo en un momento dado. Los bloqueos se
liberan al final de la transacción. Se considera como muy malo para el rendimiento y la
concurrencia de hilos/transacciones."
#. Tag: title
#: Transactions.xml:74
#, no-c-format
msgid "Insertion and Removal of Nodes"
-msgstr ""
+msgstr "Inserción y eliminación de nodos"
#. Tag: para
#: Transactions.xml:75
@@ -237,13 +251,13 @@
"<literal>false</literal>, insertions and removals of child nodes only
"
"require the acquisition of a <emphasis>read lock</emphasis> on the
parent "
"node."
-msgstr ""
+msgstr "Por defecto, antes de insertar un nuevo nodo en el árbol o antes de remover
un nodo existente del árbol, JBoss Cache tratará de adquirir un bloqueo de escritura en el
nodo padre del nodo. Este enfoque trata los nodos hijos como una parte integral del estado
de un nodo padre. Este enfoque es más correcto pero con un costo de menor concurrencia si
se añaden o se eliminan nodos con frecuencia. En casos en donde este enfoque no es útil,
JBoss Cache proporciona una opción de configuración
<literal>LockParentForChildInsertRemove</literal>. Si esto se configura como
<literal>false</literal>, las inserciones o la eliminación de nodos hijos
sólamente requiere la adquisición de un <emphasis>bloqueo de
lectura</emphasis> en el nodo padre. "
#. Tag: title
#: Transactions.xml:83
#, no-c-format
msgid "Optimistic locking"
-msgstr ""
+msgstr "Bloqueo optimista"
#. Tag: para
#: Transactions.xml:84
@@ -256,13 +270,13 @@
"locking allows for greater concurrency of threads and transactions by using "
"a technique called data versioning, explained here. Note that isolation "
"levels (if configured) are ignored if optimistic locking is enabled."
-msgstr ""
+msgstr "La motivación para el bloqueo optimista es mejorar la concurrencia. Cuando
bastantes hilos necesitan acceder al aŕbol de datos puede llegar a ser bastante
ineficiente el bloquear partes del árbol -para lectura o para escritura- durante toda una
transacción como lo hacemos en el bloqueo pesimista. El bloqueo optimista permite una
mayor concurrencia de hilos y transacciones utilizando una técnica llamada versión de
datos que vamos a explicar aqui. Observe que los niveles de aislamiento (si se configuran)
se ignoran si el bloqueo optimista se encuentra habilitado. "
#. Tag: title
#: Transactions.xml:88
#, no-c-format
msgid "Architecture"
-msgstr ""
+msgstr "Arquitectura"
#. Tag: para
#: Transactions.xml:89
@@ -276,6 +290,9 @@
"invocation completes. Each transaction maintains a transaction workspace, "
"which contains a copy of the data used within the transaction."
msgstr ""
+"El bloqueo optimista trata todas las llamadas de método como
transaccionales<footnote><para> "
+"Debido a este requerimiento siempre debe contar con un administrador de
transacciones configurado al utilizar el bloqueo optimista. </para>
</footnote>. Incluso si no invoca una llamda dentro del ámbito de una transacción en
curso, JBoss Cache "
+"crea una transacción implícita y guarda los cambios de esta transacción cuando la
invocación se completa. Cada transacción mantiene un espacio de trabajo, el cual contiene
una copia de los datos usados dentro de la transacción."
#. Tag: para
#: Transactions.xml:95
@@ -291,7 +308,7 @@
"change it and commit before the first transaction can finish - the "
"transaction throws a <literal>RollbackException</literal> when
committing "
"and the commit fails."
-msgstr ""
+msgstr "Por ejemplo, si una transacción llama a get(\"/a/b/c\"), los nodos
a, b y c son copiados desde el árbol principal de datos en el espacio de trabajo. Se le da
una versión a los datos y todas las llamadas en la transacción trabajan en la copia de los
datos en vez de trabajar en los datos mismos. Cuando la transacción guarda los cambios, su
espacio de trabajo se fusiona en el árbol subyacente observando el número de las
versiones. Si hay alguna versión que no coincida - tal como cuando el árbol de datos mismo
tiene una versión mayor que la del espacio de trabajo, en el caso en que otra transacción
fuera a acceder los mismos datos, cámbiela y guarde los cambios antes de que la primera
transacción pueda terminar - la transacción presenta una
<literal>RollbackException</literal> al guardar los cambios y por lo tanto
falla."
#. Tag: para
#: Transactions.xml:98
@@ -301,7 +318,7 @@
"only held for a very short duration - at the start of a transaction to build
"
"a workspace, and when the transaction commits and has to merge data back "
"into the tree."
-msgstr ""
+msgstr "El bloqueo optimista utiliza los mismos bloqueos que mencionamos
anteriormente, pero los bloqueos sólo se mantienen por un cortor tiempo -al principio de
la transacción para construir un espacio de trabajo y luego cuando la transacción guarda
los cambios y tiene que fusionar los datos en el árbol."
#. Tag: para
#: Transactions.xml:101
@@ -312,7 +329,7 @@
"inevitable overhead and extra processing of maintaining workspaces, "
"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 ""
+msgstr "Así que aunque puede que el bloqueo optimista falle ocasionalmente si las
validaciones de versiones fallan o puede que ejecuten un poco más despacio que el bloqueo
pesimista debido al sobrecargo inevitable y el extra procesamiento de mantener espacios de
trabajo, los datos con versiones y la validación al guardar los cambios, este si le
proporciona un nivel casi -SERIALIZABLE de integridad de los datos manteniendo un alto
nivel de concurrencia. "
#. Tag: title
#: Transactions.xml:107
@@ -326,7 +343,7 @@
msgid ""
"Optimistic locking is enabled by using the NodeLockingScheme XML attribute, "
"and setting it to \"OPTIMISTIC\":"
-msgstr ""
+msgstr "El bloqueo optimista se habilita utilizando el atributo XML
NodeLockingScheme y configurándolo como \"OPTIMISTIC\": "
#. Tag: programlisting
#: Transactions.xml:108
@@ -354,7 +371,7 @@
#: Transactions.xml:116
#, no-c-format
msgid "Transactional Support"
-msgstr ""
+msgstr "Soporte transaccional"
#. Tag: para
#: Transactions.xml:117
@@ -366,19 +383,19 @@
"modifications are potentially<footnote><para> Depending on whether
interval-"
"based asynchronous replication is used </para> </footnote> replicated
after "
"every change (if replication is enabled)."
-msgstr ""
+msgstr "JBoss Cache se puede configurara para utilizar transacciones que reunan
unidades de trabajo, las cuales después pueden ser replicadas como una unidad.
Alternativamente, si el soporte de transacción se deshabilita, es equivalente a configurar
AutoCommit to en donde las modificaciones son potencialmente<footnote><para>
Dependiendo de si utiliza la replicación asincrónica basada en intervalos</para>
</footnote> replicadas después de cada cambio (si la replicación está
habilitada)."
#. Tag: para
#: Transactions.xml:123
#, no-c-format
msgid "What JBoss Cache does on every incoming call (e.g. put()) is:"
-msgstr ""
+msgstr "Lo que JBoss Cache hace en cada llamada entrante es (por ejemplo, put()):
"
#. Tag: para
#: Transactions.xml:128
#, no-c-format
msgid "get the transaction associated with the thread"
-msgstr ""
+msgstr "obtener la transacción asociada con el hilo"
#. Tag: para
#: Transactions.xml:133
@@ -386,7 +403,7 @@
msgid ""
"register (if not already done) with the transaction manager to be notified "
"when a transaction commits or is rolled back."
-msgstr ""
+msgstr "registrar (si todavía no se ha hecho) con el administrador de transacciones
para que sea notificado cuando una transacción guarda cambios o si los deshace."
#. Tag: para
#: Transactions.xml:138
@@ -396,6 +413,8 @@
"<literal>TransactionManagerLookup</literal> which returns a
<literal>javax."
"transaction.TransactionManager</literal>."
msgstr ""
+"Con elf in de lograr esto, el caché tiene que ser configurado con una instancia de
un <literal>TransactionManagerLookup</literal>, el cual retorna un
<literal>javax."
+"transaction.TransactionManager</literal>."
#. Tag: para
#: Transactions.xml:141
@@ -413,6 +432,11 @@
"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 se envía junto con
<literal>JBossTransactionManagerLookup</literal> y "
+"<literal>GenericTransactionManagerLookup</literal>. El "
+"<literal>JBossTransactionManagerLookup</literal> se puede enlazara a un
JBoss Application Server ya en ejecución y puede recuperar un
<literal>TransactionManager</"
+"literal> mientras que el
<literal>GenericTransactionManagerLookup</literal> se puede enlazar a los
servidores de aplicaciones Java EE más populares y proporcionan la misma funcionalidad.
También se proporciona una implementación de prueba - "
+"<literal>DummyTransactionManagerLookup</literal>, la cual se puede
utilizar para aplicaciones JBoss Cache autónomas y pruebas de unidades ejecutando por
fuera de un servidor de aplicaciones Java EE. Sin embargo, ya que es sólo de prueba no se
recomienda para uso en producción."
#. Tag: para
#: Transactions.xml:144
@@ -420,7 +444,7 @@
msgid ""
"The implementation of the
<literal>JBossTransactionManagerLookup</literal> "
"is as follows:"
-msgstr ""
+msgstr "La implementación de
<literal>JBossTransactionManagerLookup</literal> es la siguiente:"
#. Tag: programlisting
#: Transactions.xml:147
@@ -456,7 +480,7 @@
msgid ""
"The implementation looks up the JBoss Transaction Manager from JNDI and "
"returns it."
-msgstr ""
+msgstr "La implementación busca el administrador de transacciones de JBoss en JNDI y
lo retorna."
#. Tag: para
#: Transactions.xml:151
@@ -470,7 +494,7 @@
"the <literal>TreeCache</literal> registers with the transaction to be
"
"notified of transaction committed or aborted when it first encounters the "
"transaction."
-msgstr ""
+msgstr "Cuando una llama entra, el <literal>TreeCache</literal> obtiene
la transacción actual y registra la modificación bajo la transacción como clave, (si no
hay una transacción, la modificación se aplica de manera inmediata y posiblemente se
replica). Así que durante la vida de la transacción todas las modificaciones se
registrarán y se asociarán con la transacción. También el
<literal>TreeCache</literal> se registra con la transacción a ser notificada
de la transacción que ha guardado los cambios o que ha abortado cuando primero encuentra
la transacción."
#. Tag: para
#: Transactions.xml:154
@@ -478,7 +502,7 @@
msgid ""
"When a transaction rolls back, we undo the changes in the cache and release "
"all locks."
-msgstr ""
+msgstr "Cuando una transacción se deshace, deshacemos los cambios en el caché y se
liberan todos los bloqueos. "
#. Tag: para
#: Transactions.xml:157
@@ -492,6 +516,9 @@
"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 ""
+"Cuando una transacción guarda los cambios, iniciamos un protocolo en dos fases para
guardar los cambios<footnote><para> Sólo con replicación sincrónica o
invalidación. "
+"</para> </footnote> : en la primera fase, se envía un PREPARE que
contiene todas las modificaciones para la transacción actual a todos los nodos en el
"
+"clúster. Cada nodo adquiere todos los bloqueos necesarios y aplica los cambios y
luego envía un mensaje de éxito. Si un nodo en un clúster no puede adquirir todos los
bloqueos o si falla entonces envía un mensaje de falla."
#. Tag: para
#: Transactions.xml:163
@@ -503,7 +530,7 @@
"initiated: a ROLLBACK message is sent to all nodes in the cluster. On "
"reception of the ROLLBACK message, every node undoes the changes for the "
"given transaction, and releases all locks held for the transaction."
-msgstr ""
+msgstr "El coordinado del protocolo de dos fases para guardar los cambios espera por
todas las respuestas (o desconecta por tiempo, lo que ocurra primero). Si uno de los nodos
en el clúster responde FAIL (o alcanzamos el tiempo de expiración) entonces se inicia una
fase para deshacer la transacción: se envía un mensaje ROLLBACK a todos los nodos en el
clúster. Al recibir el mensaje de ROLLBACK todos los nodos deshacen los cambios para la
transacción dada y libera todos los bloqueos que se mantienen en la transacción. "
#. Tag: para
#: Transactions.xml:166
@@ -513,6 +540,8 @@
"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 ""
+"Si todas las respuestas están OK, entonces se envía un mensaje COMMIT a todos los
nodos en el "
+"clúster. Al recibir un mensaje de COMMIT, cada nodo aplica los cambios para la
transacción dad y libera todos los bloqueos asociados con la transacción."
#. Tag: para
#: Transactions.xml:169
@@ -521,7 +550,7 @@
"When we referred to 'transaction', we actually mean a global representation
"
"of a local transaction, which uniquely identifies a transaction across a "
"cluster."
-msgstr ""
+msgstr "Cuando nos referimos a una 'transacción', de hecho lo que queremos
decir es una representación global de una transacción local, la cual identifica de manera
única una transacción a través de un clúster. "
#. Tag: title
#: Transactions.xml:173
@@ -535,7 +564,7 @@
msgid ""
"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 ""
+msgstr "Vamos a ver el ejemplo de cómo utilizar JBoss Cache de una manera autónoma
(por ejemplo, por fuera de un servidor de aplicaciones) con transacciones de
prueba:"
#. Tag: programlisting
#: Transactions.xml:177
@@ -589,7 +618,7 @@
msgid ""
"The first lines obtain a user transaction using the 'JEE way' via JNDI.
Note "
"that we could also say"
-msgstr ""
+msgstr "La primera línea obtiene una transacción de usuario utilizando la manera
'JEE' por medio de JNDI. Observe que también podríamos decir:"
#. Tag: programlisting
#: Transactions.xml:182
@@ -608,7 +637,7 @@
"Then we create a new TreeCache and configure it using a PropertyConfigurator
"
"class and a configuration XML file (see below for a list of all "
"configuration options)."
-msgstr ""
+msgstr "Luego creamos un nuevo TreeCache y lo configuramos utilizando una clase
PropertyConfigurator y un archivo XML de configuración (a continuación puede ver una lista
de todas las opciones de configuración). "
#. Tag: para
#: Transactions.xml:187
@@ -623,5 +652,5 @@
"exception in the methods (e.g. lock acquisition failed), or in the two-phase
"
"commit protocol applying the modifications to all nodes in the cluster, the "
"transaction is rolled back."
-msgstr ""
+msgstr "Después iniciamos el caché. Luego iniciamos una transacción (y la asociamos
con el hilo actual internamente). Cualquier método invocado en el caché sólo se recogerá y
sólo se aplicará cuando se guarden los cambios de la transacción. En el caso anterior,
creamos un nodo \"/classes/cs-101\" y añadimos dos elementos a su mapa.
Asumiendo que el caché est á configurado para utilizar la replicación sincrónica, al
guardar los cambios de la transacción, las modificaciones se replican. Si hay una
excepción en los métodos (por ejemplo, la adquisición de un bloqueo falla) o en el
protocolo de dos fases para guardar los cambios aplicando las modificaciones a todos los
nodos en el clúster entonces la transacción se deshace. "