[jboss-cvs] JBossAS SVN: r75196 - projects/docs/enterprise/4.3/Transactions/Programmers_Guide/es-ES.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Mon Jun 30 01:36:15 EDT 2008
Author: agarcia at jboss.com
Date: 2008-06-30 01:36:15 -0400 (Mon, 30 Jun 2008)
New Revision: 75196
Modified:
projects/docs/enterprise/4.3/Transactions/Programmers_Guide/es-ES/Chapter.po
projects/docs/enterprise/4.3/Transactions/Programmers_Guide/es-ES/Chapter_03.po
projects/docs/enterprise/4.3/Transactions/Programmers_Guide/es-ES/Chapter_04.po
Log:
in progress
Modified: projects/docs/enterprise/4.3/Transactions/Programmers_Guide/es-ES/Chapter.po
===================================================================
--- projects/docs/enterprise/4.3/Transactions/Programmers_Guide/es-ES/Chapter.po 2008-06-30 05:31:56 UTC (rev 75195)
+++ projects/docs/enterprise/4.3/Transactions/Programmers_Guide/es-ES/Chapter.po 2008-06-30 05:36:15 UTC (rev 75196)
@@ -7,7 +7,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-06-26 14:33+1000\n"
+"PO-Revision-Date: 2008-06-30 15:35+1000\n"
"Last-Translator: Angela Garcia\n"
"Language-Team: <en at li.org>\n"
"MIME-Version: 1.0\n"
@@ -525,7 +525,7 @@
msgid ""
"local disk/database implementation, where locks are made persistent by being "
"written to the local file system or database."
-msgstr ""
+msgstr "la implementación local disk/database, en donde se hacen persistentes los bloqueos al ser escrito en el sistema de archivos local o en la base de datos."
#. Tag: para
#: Chapter.xml:102
@@ -536,7 +536,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 "una implementación puramente local, en donde los bloqueos se mantienen dentro de la memoria de la máquina virtual que los creó; esta implementación tiene un mejor rendimiento que el escribir bloques en el disco local, pero los objetos no se pueden compartir entre máquinas virtuales. Un punto importante a notar es que es un objeto Java básico sin requerimientos lo cual puede ser afectado por el SecurityManager"
#. Tag: para
#: Chapter.xml:105
@@ -597,7 +597,7 @@
#: Chapter.xml:113
#, no-c-format
msgid "The code below shows how we may try to obtain a write lock on an object:"
-msgstr ""
+msgstr "El código a continuación muestra la manera en que podemos tratar de obtener un bloqueo de escritura en un objeto: "
#. Tag: screen
#: Chapter.xml:115
@@ -707,7 +707,7 @@
msgid ""
"The simple example below illustrates the relationships between activation, "
"termination and commitment:"
-msgstr ""
+msgstr "El ejemplo simple que mostramos a continuación ilustra la relación entre activación, terminación y el guardar los cambios: "
#. Tag: screen
#: Chapter.xml:132
@@ -753,7 +753,7 @@
msgid ""
"The execution of the above code involves the following sequence of "
"activities:"
-msgstr ""
+msgstr "La ejecución del código anterior implica la siguiente secuencia de actividades: "
#. Tag: para
#: Chapter.xml:137
@@ -771,7 +771,7 @@
#: Chapter.xml:138
#, no-c-format
msgid "Start of the atomic transaction."
-msgstr ""
+msgstr "Inicio de la transacción atómica."
#. Tag: para
#: Chapter.xml:139
@@ -803,7 +803,7 @@
#: Chapter.xml:147
#, no-c-format
msgid "The class hierarchy"
-msgstr ""
+msgstr "La jerarquía de clases "
#. Tag: para
#: Chapter.xml:149
@@ -812,6 +812,8 @@
"The principal classes which make up the class hierarchy of <emphasis>TxCore</"
"emphasis> are depicted below."
msgstr ""
+"Las clases principales que componen la jerarquía de clases de <emphasis>TxCore</"
+"emphasis> se ilustran a continuación."
#. Tag: screen
#: Chapter.xml:151
@@ -946,12 +948,14 @@
"<classname>LockManager</classname> class, performs the following functions "
"in this case:"
msgstr ""
+"La operación <literal>setlock</literal>, que la clase <classname>LockManager</classname> proporciona, realiza las siguientes funciones "
+"en este caso:"
#. Tag: para
#: Chapter.xml:164
#, no-c-format
msgid "Check write lock compatibility with the currently held locks, and if allowed:"
-msgstr ""
+msgstr "Verifique la compatibilidad de bloqueos de escritura con los bloqueos actuales y si lo permite: "
#. Tag: para
#: Chapter.xml:165
@@ -972,7 +976,7 @@
#: Chapter.xml:166
#, no-c-format
msgid "Create and insert a LockRecord instance in the RecordList of Trans."
-msgstr ""
+msgstr "Cree e inserte una instancia LockRecord en la the RecordList de transacciones."
#. Tag: para
#: Chapter.xml:169
@@ -988,6 +992,11 @@
"<classname>RecoveryRecord</classname>/<classname>PersistenceRecord</"
"classname> will restore the prior state of O."
msgstr ""
+"Ahora suponga que la acción <literal>Trans</literal> se aborta un poco después de que se ha adquirido el bloqueo. Entonces la operación para deshacer de <classname>AtomicAction</classname> procesará la instancia <classname>RecordList</"
+"classname> asociada con <literal>Trans</literal> invocando una operación <literal>Abort</literal> apropiada en los varios records. La "
+"implementación de esta operación por la clase <classname>LockRecord</classname> "
+"liberará el bloqueo <literal>WRITE</literal> mientras que el de <classname>RecoveryRecord</classname>/<classname>PersistenceRecord</"
+"classname> restaurará el estado anterior de O."
#. Tag: para
#: Chapter.xml:171
@@ -999,5 +1008,5 @@
"appropriate lock; <emphasis>TxCore</emphasis> and <emphasis>Transactional "
"Objects for Java</emphasis> take care of participant registration, "
"persistence, concurrency control and recovery."
-msgstr ""
+msgstr "Es importante darse cuenta de que todo el trabajo realizado antes lo hace de manera automática <emphasis>TxCore</emphasis> en nombre del programador de la aplicación. El programador sólo necesita iniciar la transacción y establecer un bloqueo apropiado; <emphasis>TxCore</emphasis> y los <emphasis>objetos transaccionales para Java</emphasis> se preocupan del registro de los participantes, la persistencia, el control de concurrencia y la recuperación. "
Modified: projects/docs/enterprise/4.3/Transactions/Programmers_Guide/es-ES/Chapter_03.po
===================================================================
--- projects/docs/enterprise/4.3/Transactions/Programmers_Guide/es-ES/Chapter_03.po 2008-06-30 05:31:56 UTC (rev 75195)
+++ projects/docs/enterprise/4.3/Transactions/Programmers_Guide/es-ES/Chapter_03.po 2008-06-30 05:36:15 UTC (rev 75196)
@@ -7,7 +7,7 @@
"Project-Id-Version: Chapter_03\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2008-06-05 22:51+0000\n"
-"PO-Revision-Date: 2008-06-25 14:56+1000\n"
+"PO-Revision-Date: 2008-06-30 13:18+1000\n"
"Last-Translator: Angela Garcia\n"
"Language-Team: <en at li.org>\n"
"MIME-Version: 1.0\n"
@@ -19,13 +19,13 @@
#: Chapter_03.xml:6
#, no-c-format
msgid "General Transaction Issues"
-msgstr ""
+msgstr "Consideraciones sobre transacciones generales"
#. Tag: title
#: Chapter_03.xml:10
#, no-c-format
msgid "Advanced transaction issues with TxCore"
-msgstr ""
+msgstr "Consideraciones sobre transacciones avanzadas con TxCore"
#. Tag: para
#: Chapter_03.xml:12
@@ -36,13 +36,13 @@
"made atomic as required by the semantics of a particular operation. This "
"chapter will describe some of the more subtle issues involved with using "
"transactions in general and <emphasis>TxCore</emphasis> in particular."
-msgstr ""
+msgstr "Tanto los programadores de las aplicaciones como los desarrolladores de las clases pueden utilizar las acciones atómicas (transacciones). Por lo tanto las operaciones completas (o partes de operaciones) se pueden hacer atómicas cuando se necesite por medio de la semántica de una operación en particular. Este capítulo describirá algunos de los problemas más sutiles relacionados con el uso de transacciones en general y <emphasis>TxCore</emphasis> en particular."
#. Tag: title
#: Chapter_03.xml:15
#, no-c-format
msgid "Checking transactions"
-msgstr ""
+msgstr "Verificación de transacciones "
#. Tag: para
#: Chapter_03.xml:17
@@ -65,6 +65,8 @@
"instance of this class associated with it, and application programmers can "
"provide their own implementations on a per transaction basis."
msgstr ""
+"En una aplicación con multi-hilos, múltiples hilos se pueden asociar con una transacción durante su tiempo de vida, por ejemplo, los hilos comparte en contexto. Además, es posible que si un hilo termina una transacción puede que otros hilos aún se encuentren activos dentro de él. En un entorno distribuido puede ser dificil el garantizar que todos los hilos hayan terminado con una transacción esta se termina. Por defecto, <emphasis>TxCore</emphasis> emitirá una advertencia si un hilo termina una transacción cuando otros hilos aún se encuentran activos dentro de él; sin embargo, le permitirá continuar con la terminación de la transacción. Hay otras soluciones posibles para este problema, por ejemplo, bloquear el hilo que está terminando la transacción hasta que todos los otros hilos se hayan desasociado a sí mismos del contexto de la transacción. Por lo tanto, <emphasis>TxCore</emphasis> proporciona la clase <classname>com.arjuna.ats.arjuna."
+"coordinator.CheckedAction</classname>, la cual permite sobreescribir la política de terminación de transacciones/hilos. Cada transacción tiene una instancia de esta clase asociada consigo y los programadores de aplicaciones pueden proporcionar sus propias implementaciones transacción por transacción."
#. Tag: programlisting
#: Chapter_03.xml:19
@@ -94,7 +96,7 @@
"threads within it, the system will invoke the check method on the "
"transaction’s <classname>CheckedAction</classname> object. The parameters to "
"the check method are:"
-msgstr ""
+msgstr "Cuando un hilo intenta terminar la transacción y aún hay hilos activos dentro de esta, el sistema invocará el método de verificación en el objeto <classname>CheckedAction</classname> de la transacción. Los parámetros para verificar el método son: "
#. Tag: term
#: Chapter_03.xml:25
@@ -108,7 +110,7 @@
msgid ""
"Indicates whether the transaction is in the process of committing or rolling "
"back."
-msgstr ""
+msgstr "Indica si la transacción está en proceso de guardar los cambios o de deshacerlos. "
#. Tag: term
#: Chapter_03.xml:30
@@ -143,13 +145,13 @@
"When check returns, the transaction termination will continue. Obviously the "
"state of the transaction at this point may be different from that when check "
"was called, e.g., the transaction may subsequently have been committed."
-msgstr ""
+msgstr "Cuando la verificación retorna, la terminación de la transacción continua. Obviamente el estado de la transacción en este punto puede ser diferente de cuando se realizó la verficicación, por ejemplo, puede que la transacción haya guardado los cambios posteriormente. "
#. Tag: title
#: Chapter_03.xml:47
#, no-c-format
msgid "Statistics gathering"
-msgstr ""
+msgstr "Estadísticas en conjunto"
#. Tag: para
#: Chapter_03.xml:49
@@ -163,6 +165,9 @@
"during the execution of a transactional application via the <classname>com."
"arjuna.TxCore.Atomic.TxStats</classname> class:"
msgstr ""
+"Por defecto, JBossTS no mantiene ningún historial sobre las transacciones. Sin embargo, al configurar variable de la propiedad <literal>com.arjuna.ats.arjuna."
+"coordinator.enableStatistics</literal> como YES, el servicio de transacciones mantendrá información sobre el número de transacciones creadas y sus resultados. Esta información se puede obtener durante la ejecución de una aplicación transaccional por medio de la clase <classname>com."
+"arjuna.TxCore.Atomic.TxStats</classname>:"
#. Tag: programlisting
#: Chapter_03.xml:51
@@ -246,7 +251,7 @@
#: Chapter_03.xml:57
#, no-c-format
msgid "Last resource commit optimisation"
-msgstr ""
+msgstr "Optimización para guardar los cambios del último recurso"
#. Tag: para
#: Chapter_03.xml:59
@@ -266,6 +271,8 @@
"logs the decision to commit and attempts to commit the other resources as "
"well."
msgstr ""
+"En algunos casoso es necesario listar los participantes que no están concientes de que el guardar los cambios se realiza en dos fases en una transacción de guardado en dos fases. Si sólo hay un sólo recurso entonces no es necesario guardar los cambios en dos fases. Sin embargo, ¿qué pasa si hay múltiples recursos en la transacción? En este caso, tiene lugar la optimización para guardar cambios del último recurso (LRCO del inglés Last "
+"Resource Commit optimization). Es posible que un sólo recurso que sea conciente de una fase (por ejemplo, sólo puede guardar los cambios o deshacerlos, sin un prepare) que se enliste en una transacción con recursos concientes de guardar los cambios en dos fases. El coordinador trata el recurso conciente de una fase de manera diferente en que este ejecuta la fase de preparación en todos los otros recursos primero y luego si quiere guardar la transacción entonces le pasa el control al recurso conciente de una fase. Si guarda los cambios entonces el coordinador registra la decisión para guardar los cambios y trata de guardar los cambios de los otros recursos también. "
#. Tag: para
#: Chapter_03.xml:61
@@ -279,6 +286,11 @@
"<classname>com.arjuna.ats.arjuna.LastResourceRecord</classname> and give "
"your participant as the constructor parameter, as shown below:"
msgstr ""
+"Con el fin de utilizar LRCO, su participante debe implementar la interfaz "
+"<classname>com.arjuna.ats.arjuna.coordinator.OnePhase</classname> y registrarse con la transacción por medio de la operación <command>BasicAction</"
+"command>.add ya que esta operación espera instancias de "
+"<classname>AbstractRecord</classname>, debe crear una instancia "
+"<classname>com.arjuna.ats.arjuna.LastResourceRecord</classname> y dar su participante como el parámetro constructor, como se muestra a continuación:"
#. Tag: programlisting
#: Chapter_03.xml:63
@@ -334,7 +346,7 @@
"may be nested. Objects written in this way can then be shared between "
"application programmers, and <emphasis>TxCore</emphasis> will guarantee "
"their consistency."
-msgstr ""
+msgstr "No hay construcciones especiales para anidar transacciones. Si una acción se inicia mientras que otra acción está ejecutando entonces se anida de manera automática. Esto permite una estructura modular en las aplicaciones, en donde los objetos se pueden implementar utilizando acciones atómicas dentro de sus operaciones sin que el programador de aplicaciones se tenga que preocupar de las aplicaciones que las utilizarán, por ejemplo, si las aplicaciones utilizarán o no acciones atómicas también. Por lo tanto en algunas acciones de las aplicaciones puede ser el nivel superior mientras que en otras puede se anidado. Los objetos escritos de esta manera se pueden compartir entre programadores de aplicaciones y <emphasis>TxCore</emphasis> garantizará su consistencia. "
#. Tag: para
#: Chapter_03.xml:72
@@ -346,7 +358,7 @@
"commits then the work it has performed will only be committed by the system "
"if the top-level action commits; if the top-level action aborts then all of "
"the work will be undone."
-msgstr ""
+msgstr "Si una acción anidada se aborta entonces se deshace todo su trabajo, aunque el bloqueo estricto de dos fases significa que cualquier bloqueo que se pudo haber obtenido se retendrá hasta que la acción a nivel superior guarde los cambio o aborte. Si una acción anidada guarda los cambios entonces el trabajo que ha realizado sólo será guardado por el sistema si la acción a nivel superior guarda los cambios, si la acción a nivel superior aborta entonces todo el trabajo se deshace. "
#. Tag: para
#: Chapter_03.xml:74
@@ -356,13 +368,13 @@
"the outcome of the action within which it is nested. This is application "
"dependant, and allows a programmer to structure atomic actions to contain "
"faults, undo work, etc."
-msgstr ""
+msgstr "El guardar los cambios o el abortar una acción anidada no afecta de manera automática el resultado de la acción dentro de la cual se encuentra anidado. Esta aplicación es dependiente y le permite al programador estructurar acciones atómicas para que contengan fallas, trabajos deschechos, etc. "
#. Tag: title
#: Chapter_03.xml:78
#, no-c-format
msgid "Asynchronously committing a transaction"
-msgstr ""
+msgstr "Guardar los cambios de una transacción de manera asincrónica"
#. Tag: para
#: Chapter_03.xml:80
@@ -372,7 +384,7 @@
"in a synchronous manner, i.e., all registered resources will be told to "
"prepare in order by a single thread, and then they will be told to commit or "
"rollback. This has several possible disadvantages:"
-msgstr ""
+msgstr "Por defecto, JBossTS ejecuta el protocolo para guardar cambios de una transacción a nivel superior de una manera asincrónica, por ejemplo, se le dirá a todos los recursos registrados que se preparen en orden de un sólo hilo y luego se les dirá que guarden los cambios o que los deshagan. Esto tiene vasrias desventajas posibles: "
#. Tag: para
#: Chapter_03.xml:83
@@ -383,7 +395,7 @@
"if an “early” resource in the list of registered resource forces a rollback "
"during prepare, possibly many prepare operations will have been made "
"needlessly."
-msgstr ""
+msgstr "En el caso de que haya muchos recursos registrados, el prepare se puede invocar lógicamente en paralelo en cada recurso. La desventaja es que si un recurso 'temprano' en la lista de recursos registrados fuerza el deshacer los cambios durante la fase prepare, posiblemente muchas operaciones prepare se habrán hecho de manera innecesaria. "
#. Tag: para
#: Chapter_03.xml:84
@@ -392,7 +404,7 @@
"In the case where heuristic reporting is not required by the application, "
"the second phase of the commit protocol can be done asynchronously, since "
"its success or failure is not important."
-msgstr ""
+msgstr "En el casi en donde la aplicación no requiere un reporte huerístico, la segunda fase del protocolo para guardar los cambios se puede hacer de manera asincrónica ya que no tiene mayor importancia si tiene éxito o no. "
#. Tag: para
#: Chapter_03.xml:87
@@ -408,12 +420,17 @@
"second phase of the transaction if knowledge about heuristics outcomes is "
"not required."
msgstr ""
+"Por lo tanto, <emphasis>JBossTS</emphasis> proporciona las opciones en tiempo de ejecución para habilitar posibles optimizaciones de hilos. Al configurar la variable de entorno <literal>com.arjuna.ats."
+"arjuna.coordinator.asyncPrepare</literal> como "
+"<literal>YES</literal>, durante la fase prepare se creará un hilo separado para cada participante registrado dentro de la transacción. Al configurar "
+"<literal>com.arjuna.ats.arjuna.coordinator.asyncCommit</literal> como "
+"<literal>YES</literal>, se creará un hilo separado para completar la segunda fase de la transacción si no se requiere el conocimiento sobre resultados heurísticos. "
#. Tag: title
#: Chapter_03.xml:93
#, no-c-format
msgid "Independent top-level transactions"
-msgstr ""
+msgstr "Transacciones independientes a nivel superior"
#. Tag: para
#: Chapter_03.xml:95
@@ -427,12 +444,14 @@
"made permanent when it commits and will not be undone if any of the actions "
"within which it was originally nested abort."
msgstr ""
+"Además de las acciones atómicas anidadas y normales a nivel superior <emphasis>TxCore</"
+"emphasis> también soporta acciones independientes a nivel superior, las cuales se pueden utilizar para relajar la rerializabilidad estricta de una manera controlada. Una acción independiente a nivel superior se puede ejecutar desde cualquier lugar dentro de otra acción atómica y se comporta exactamente igual que una acción normal a nivel superior, es decir, sus resultados se hacen permanentes cuando guarda los cambios y no se deshacen si cualquiera de las acciones dentro de la cual se anidó originalmente aborta."
#. Tag: caption
#: Chapter_03.xml:101
#, no-c-format
msgid "Independent Top-Level Action"
-msgstr ""
+msgstr "Acción independiente a nivel superior "
#. Tag: para
#: Chapter_03.xml:104
@@ -445,7 +464,7 @@
"other actions within the structure. Because of the nature of independent top-"
"level actions they should be used with caution and only in situations where "
"their use has been carefully examined."
-msgstr ""
+msgstr "muestra un anidado típico de acciones atómicas, en donde la acción B se anida dentro de la acción A. Aunque la acción atómica C está anidada lógicamente dentro de la acción B (su operación Begin se invocó mientras que B estaba activo) debido a que es una acción independiente a nivel superior, guardará los cambios o abortará de manera independiente de las otras acciones dentro de la estructura. Gracias a la naturaleza de las acciones independientes a nivel superior estas se deben utilizar con mucho cuidado y sólo en situaciones en donde su uso se ha examinado de manera cuidadosa. "
#. Tag: para
#: Chapter_03.xml:106
@@ -454,13 +473,13 @@
"Top-level actions can be used within an application by declaring and using "
"instances of the class <classname>TopLevelTransaction</classname>. They are "
"used in exactly the same way as other transactions."
-msgstr ""
+msgstr "Las acciones a nivel superior se pueden utilizar dentro de una aplicación declarando y utilizando instancias de la clase <classname>TopLevelTransaction</classname>. Estas se utilizand exactamente de la misma manera que las otras transacciones. "
#. Tag: title
#: Chapter_03.xml:111
#, no-c-format
msgid "Transactions within save_state and restore_state"
-msgstr ""
+msgstr "Transacciones dentro de save_state y restore_state"
#. Tag: para
#: Chapter_03.xml:113
@@ -476,6 +495,9 @@
"violate the atomicity properties of the action being committed (aborted) and "
"is thus discouraged."
msgstr ""
+"Debe tener mucho cuidado al escribir las operaciones <command>save_state</command> y "
+"<command>restore_state</command> para asegurarse de no iniciar ninguna acción atómica (ya sea explícitamente en la operación o implícitamente por medio del uso de alguna otra operación). Esta restricción surge ya que puede que "
+"<emphasis>TxCore</emphasis> invoque <command>restore_state</command> como parte de su proceso de guardar cambios lo que resulta en un intento de ejecutar una acción atómica durante la fase para guardar cambios o de abortar de otra acción. Esto puede llegar a violar las propiedades de atomicidad de la acción que se está guardando (o abortando) y por lo tanto no se aconseja que la utilice."
#. Tag: title
#: Chapter_03.xml:118
@@ -489,7 +511,7 @@
msgid ""
"If we consider the Array example given previously, the set and get "
"operations could be implemented as shown below."
-msgstr ""
+msgstr "Si consideramos el ejemplo de la lista que vimos antes, las operaciones set y get se pueden implementar como se muestra a continuación."
#. Tag: para
#: Chapter_03.xml:122
@@ -497,7 +519,7 @@
msgid ""
"This is a simplification of the code, ignoring error conditions and "
"exceptions."
-msgstr ""
+msgstr "Este es una simplificación del código que ignora errores y excepciones. "
#. Tag: programlisting
#: Chapter_03.xml:124
@@ -607,13 +629,13 @@
"object maintained by an application, <emphasis>TxCore</emphasis> will always "
"retain its own references to ensure that the object is not garbage collected "
"until after any transaction has terminated."
-msgstr ""
+msgstr "Los objetos Java se borran cuando el recolector de basura determina que ya no se necesitan. El borrar un objeto se encuentra actualmente bajo el control de una transacción se debe realizar con mucho cuidado ya que si el objeto está siendo manipulado dentro de una transacción, su destino está determinado por la transacción. Por lo tanto, sin importar las referencias a un objeto transaccional mantenido por una aplicación, <emphasis>TxCore</emphasis> siempre retendrá sus propias referencias para asegurarse de que el objeto no sea recogido por la basura si no hasta que se haya terminado cualquier transacción. "
#. Tag: title
#: Chapter_03.xml:136
#, no-c-format
msgid "Transaction timeouts"
-msgstr ""
+msgstr "Expiración de transacciones "
#. Tag: para
#: Chapter_03.xml:138
@@ -624,7 +646,7 @@
"timeout (in seconds) on a per transaction basis such that if the transaction "
"has not terminated before the timeout expires it will be automatically "
"rolled back."
-msgstr ""
+msgstr "Por defecto las transacciones viven hasta que la aplicación que las creó las termina o hasta que ocurre una falla. Sin embargo, is posible configurar un tiempo de expiración (en segundos) transacción por transacción de tal manera que si la transacción no ha terminado antes de que el tiempo de exipración se cumpla entonces se desharán la transacción automáticamente. "
#. Tag: para
#: Chapter_03.xml:140
@@ -639,6 +661,10 @@
"property <literal>com.arjuna.ats.arjuna.coordinator.defaultTimeout</"
"literal>. Unless changed the default value is 60 seconds."
msgstr ""
+"En <emphasis>TxCore</emphasis>, el valor del tiempo de expiración se proporciona como un parámetro "
+"para el constructor <classname>AtomicAction</classname>. Si se proporciona un valor de "
+"<literal>AtomicAction.NO_TIMEOUT</literal> (el predeterminado) entonces la transacción no expirará de manera automática. Cualquier otro valor positivo se asume para el tiempo de expiración de la transacción (en segundos). Un valor de cero se toma como un tiempo de expiración global predeterminado, el cual lo puede proveer la propidad <literal>com.arjuna.ats.arjuna.coordinator.defaultTimeout</"
+"literal>. A menos de que se cambie el valor predeterminado es 60 segundos."
#. Tag: para
#: Chapter_03.xml:142
@@ -658,6 +684,10 @@
"transaction times out. This has the advantage of terminating transactions "
"early, but may suffer from continually rescheduling the reaper thread."
msgstr ""
+"Cuando se crea una transacción a nivel superior con un tiempo de expiración diferente a cero, está sujeto a ser deshecho si no se ha completado dentro del número de segundos especificado. <emphasis>JBossTS</emphasis> utiliza un reaper thread separado, el cual monitorea todas las transacciones creadas localmente y las fuerza a deshacerlas si sus tiempos de expiración se acaban. Para prevenir que este hilo consuma el tiempo de la aplicación, sólo ejecuta periódicamente. El tiempo predeterminado de verificación es 120000 millisegundos, pero se puede sobreescribir configurando la variable de la propiedad <literal>com."
+"arjuna.ats.arjuna.coordinator.txReaperTimeout</literal> con otro valor válido, en microsegundos. De manera alterna, si el <literal>com."
+"arjuna.ats.arjuna.coordinator.txReaperMode</literal> se configura como "
+"<literal>DYNAMIC</literal>, entonces el transaction reaper se despertará cuando una transacción expire. Esto tiene la ventaja de terminar transacción de manera temprana pero puede que tenga que reprogramar el reaper thread continuamente. "
#. Tag: para
#: Chapter_03.xml:144
@@ -672,4 +702,7 @@
"emphasis>, or <literal>com.arjuna.ats.jts.defaultTimeout</literal> if using "
"<emphasis>ArjunaJTS</emphasis>, to the required timeout value in seconds."
msgstr ""
+"Si se especifica un valor de 0 para el tiempo de expiración de una transacción a nivel superior ( o no se especifica un tiempo de expiración) entonces <emphasis>JBossTS</emphasis> no impondrá ningún tiempo de expiración en la transacción, por ejemplo, se le permitirá que ejecute indefinidamente. El tiempo de expiración predeterminado se puede sobreescribir configurando la variable de la propiedad <literal>com.arjuna.ats.arjuna.coordinator.defaultTimeout</literal> al utilizar <emphasis>ArjunaCore</emphasis> o <emphasis>ArjunaJTS</"
+"emphasis>, o <literal>com.arjuna.ats.jts.defaultTimeout</literal> si usa"
+"<emphasis>ArjunaJTS</emphasis>"
Modified: projects/docs/enterprise/4.3/Transactions/Programmers_Guide/es-ES/Chapter_04.po
===================================================================
--- projects/docs/enterprise/4.3/Transactions/Programmers_Guide/es-ES/Chapter_04.po 2008-06-30 05:31:56 UTC (rev 75195)
+++ projects/docs/enterprise/4.3/Transactions/Programmers_Guide/es-ES/Chapter_04.po 2008-06-30 05:36:15 UTC (rev 75196)
@@ -7,7 +7,7 @@
"Project-Id-Version: Chapter_04\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2008-06-05 22:51+0000\n"
-"PO-Revision-Date: 2008-06-25 14:57+1000\n"
+"PO-Revision-Date: 2008-06-30 15:08+1000\n"
"Last-Translator: Angela Garcia\n"
"Language-Team: <en at li.org>\n"
"MIME-Version: 1.0\n"
@@ -19,7 +19,7 @@
#: Chapter_04.xml:6
#, no-c-format
msgid "Hints and tips"
-msgstr ""
+msgstr "Consejos"
#. Tag: title
#: Chapter_04.xml:9
@@ -47,7 +47,7 @@
"however, the constructor transaction commits but is nested because some "
"other transaction started prior to object creation is running, then the "
"state will be written only if all of the parent transactions commit."
-msgstr ""
+msgstr "Los ejemplos incluidos en este manual utilizan transacciones en la implementación de constructores para nuevos objetos persistentes. Esto se hizo deliberadamente ya que garantiza la propagación correcta del estado del objeto para el almacenamiento de objetos. Recuerde que el estado de un objeto persistente modificado sólo se escribe en el almacenmaiento de objetos cuando la transacción a nivel superior guarda los cambios. Por lo tanto si la transacción constructora se encuentra a nivel superior y guarda los cambios entonces el objeto recién creado se escribe en el almacenamiento y se hace disponible de manera inmediata. Sin embargo, si la transacción constructora guarda los cambios pero es anidada ya que alguna otra transacción empezó antes de ejecutar la creación del objeto entonces el estado sólo se escribirá si todas las transacciones padre guardan los cambios. "
#. Tag: para
#: Chapter_04.xml:16
@@ -58,7 +58,7 @@
"transaction is active when the object is created then its state will not be "
"saved to the store until the next time the object is modified under the "
"control of some transaction."
-msgstr ""
+msgstr "Por otro lado, si el constructor no utiliza transacciones entonces es posible que surjan inconsistencias en el sistema. Por ejemplo, si no hay transacción activa cuando el objeto se crea entonces su estado no se guardará en el almacenamiento hasta la próxima vez que el objeto sea modificado bajo el control de alguna transacción. "
#. Tag: para
#: Chapter_04.xml:18
@@ -112,12 +112,16 @@
"been saved at the time it was constructed and this inconsistency could not "
"arise."
msgstr ""
+"Aquí los dos objetos se crean fuera del control de la acción superior A. <literal>obj1</literal> es un nuevo objeto; <literal>obj2</literal> es un objeto viejo ya existente. Cuando la operación remember de <literal>obj2</"
+"literal> se invoca el objeto se activará y el Uid de "
+"<literal>obj1</literal> se recordará. Ya que esta acción guarda los cambios del estado persistente de <literal>obj2</literal> ahora contiene el Uid de <literal>obj1</"
+"literal>. Sin embargo, el estado de <literal>obj1</literal> no ha sido guardado ya que no ha sido manipulado bajo el control de cualquier acción. De hecho, a menos de que se modifique bajo el control de alguna acción después en la aplicación nunca se guardará. Sin embargo, si el constructor había utilizado una acción atómica el estado de <literal>obj1</literal> se habría guardado de manera automática cuando fue construido y esta inconsistencia no podía haber surgido."
#. Tag: title
#: Chapter_04.xml:26
#, no-c-format
msgid "More on save_state and restore_state"
-msgstr ""
+msgstr "Un poco más sobre save_state y restore_state"
#. Tag: para
#: Chapter_04.xml:28
@@ -130,6 +134,8 @@
"therefore, that all of the variables saved by save_state are correctly "
"initialised."
msgstr ""
+"<emphasis>TxCore</emphasis> puede invocar la operación definida por el usuario <command>save_state</"
+"command> de un objeto efectivamente en cualquier momento durante el tiempo de vida de un objeto incluyendo durante la ejecución del cuerpo del constructor del objeto (particularmente si utiliza acciones atómicas). Por lo tanto es importante que todas las variables que se guarden con save_state se incialicen de manera correcta."
#. Tag: para
#: Chapter_04.xml:30
@@ -145,6 +151,9 @@
"transaction. This might violate the atomicity properties of the transaction "
"being committed (aborted) and is thus discouraged."
msgstr ""
+"Debe tener también mucho cuidado al escribir las operaciones <command>save_state</"
+"command> y <command>restore_state</command> y asegurarse de que no se han iniciado transacciones (ya sea de manera explícita en la operación o implicitamente por medio del uso de alguna otra operación). Esta restricción surge debido al hecho de que <emphasis>TxCore</emphasis> puede invocar <command>restore_state</"
+"command> como parte de su proceso de guardar los cambios lo que hace que se intente ejecutar una transacción atómica durante la fase de guardar los cambios o de abortar de otra transacción. Esto puede llegar a violar las propiedades de atomicidad de la transacción que se está guardando (o abortando) y por lo tanto no la sugerimos."
#. Tag: para
#: Chapter_04.xml:32
@@ -155,6 +164,8 @@
"methods of user objects to call <command>super.save_state</command> and "
"<command>super.restore_state</command>."
msgstr ""
+"Con el fin de soportar la recuperación de fallos para objetos persistentes es necesario para todos los métodos <literal>save_state</literal> y <literal>restore_state</literal> de objetos de usuario llamar a <command>super.save_state</command> y a "
+"<command>super.restore_state</command>."
#. Tag: title
#: Chapter_04.xml:37
@@ -174,6 +185,9 @@
"problems of aliasing. That is two different object references may in actual "
"fact point at the same item. For example:"
msgstr ""
+"Todos los tipos básicos de Java (int, long, etc) se pueden guardar y reestablecer desde una instancia <classname>Input/OutputObjectState</classname> usando las rutinas "
+"pack (y unpack) que <classname>Input/OutputObjectState</"
+"classname> proporciona. Sin embargo el empacar y desempacar objetos se debe manejar de manera diferente. Esto se debe a que el empaque de objetos trae consigo los problemas adicionales de los alias. Esto se refiere a cuando las referencias de dos objetos diferentes de hecho apuntan al mismo objeto, por ejemplo: "
#. Tag: programlisting
#: Chapter_04.xml:41
@@ -219,6 +233,9 @@
"original aliasing information. The current version of TxCore will pack and "
"unpack separate object references."
msgstr ""
+"Aquí, tanto s1 como s2 apuntan a la misma cadena y una implementación inocente de "
+"<command>save_state</command> podría terminar en copiar la cadena dos veces. Desde una perspectiva <command>save_state</command> esto simplemente es ineficiente. "
+"Sin embargo, esto hace que <command>restore_state</command> sea incorrecto ya que desempacaría las dos cadenas en áreas diferentes de la memoria lo que destruiría la información original sobre los alias. La versión actual de TxCore empacará y desempacará referencias de objetos separados."
#. Tag: title
#: Chapter_04.xml:49
@@ -238,6 +255,8 @@
"persistence and recovery mechanisms is required, direct derivation of a user "
"class from <classname>StateManager</classname> is possible."
msgstr ""
+"Los ejempolos en este manual siempre han derivado las clases de usuario de "
+"<classname>LockManager</classname>. La razón para esto es doble. Primero, y la razón más importante, las restricciones de seriabilidad de acciones atómicas que la requieren y segundo reduce la necesidad de intervención del programador. Sin embargo, si sólo se requiere acceso a los mecanismos de recuperación y de persistencia de <emphasis>TxCore</emphasis> entonces es posible la derivación directa de la clase de un usuario de <classname>StateManager</classname>."
#. Tag: para
#: Chapter_04.xml:53
@@ -251,6 +270,10 @@
"classname>'s constructors are effectively identical to those of "
"<classname>LockManager</classname>."
msgstr ""
+"Las clases derivadas directamente de <classname>StateManager</classname> deben hacer uso de sus mecanismos de administración de estado de manera explícita (estas interacciones normalmente las toma el <classname>LockManager</classname>). Desde el punto de vista de un programador llega hasta hacer uso apropiado de las the "
+"operaciones activate, deactivate y modified, ya que los constructores del <classname>StateManager</"
+"classname> son efectivamente idénticos a aqueloos del "
+"<classname>LockManager</classname>."
#. Tag: programlisting
#: Chapter_04.xml:55
@@ -275,6 +298,8 @@
"of the object store to search for the object. A value of null means use the "
"default store."
msgstr ""
+"<command>Activate</command> carga un objeto desde el almacenamiento de objetos. El UID del objeto ya debe estar configurado por medio del constructor y el objeto debe existir en el almacenamiento. Si el objeto se lee de manera exitosa entonces se llama a <command>restore_state</command> para construir el objeto en memoria. "
+"<command>Activate</command> es id impotente así que una vez un objeto haya sido activado se ignoran las llamadas siguientes. El parámetro representa el nombre raíz del almacenamiento de objetos para buscar el objeto. Un valor de nulo significa utilizar el lamacenamiento predeterminado."
#. Tag: programlisting
#: Chapter_04.xml:59
@@ -295,13 +320,13 @@
"Objects are only saved if they have been modified since they were activated. "
"The parameter represents the root name of the object store into which the "
"object should be saved. A value of null means use the default store."
-msgstr ""
+msgstr "Los inverso de activate. Primero llama a <command>save_state</command> para construir la imagen compacta del objeto, el cual luego se guarda en el almacenamiento de objetos. Los objetos sólo se guardan si han sido modificado desde que fueron activados. El parámetro representa el nombre raíz del almacenamiento de objetos en el cual se debe guardar el objeto. Un valor de nulo significa que utiliza el almacenamiento predeterminado."
#. Tag: programlisting
#: Chapter_04.xml:63
#, no-c-format
msgid "void modified ()"
-msgstr ""
+msgstr "void modified ()"
#. Tag: para
#: Chapter_04.xml:65
@@ -310,5 +335,5 @@
"<emphasis>Must</emphasis> be called prior to modifying the object in memory. "
"If it is not called the object will not be saved in the object store by "
"deactivate."
-msgstr ""
+msgstr "<emphasis>Tiene</emphasis> que llamarlo antes de modificar el objeto en memoria. Si no lo llama deactivate no guardará el objeto en el almacenamiento de objetos."
More information about the jboss-cvs-commits
mailing list