En el thread de ReStore comentaba que use Omnibase pero que todavia no
tenía en claro una política de trabajo para manejar las Transacciones y
Sergio me sugirió que habrá otro thread con este tema así que acá esta.
Una cosa que me recomendaron desde el comienzo en la lista, y que confirmé es que hay que pensar de cierta forma a la hora de tarbajar con una base de datos de objetos.
Tenes que entender que el sistema está "dormido" (es decir, todos los objetos están persistidos) y que cada interaccion del sistema la tenés que plantear en términos de:
-Está todo dormido
-Levanto los objetos que voy a usar
-Hago lo que tengo que hacer
-Commiteo y tiro la transaccion, dejando a todos los objetos dormiditos de nuevo
Este esquema de trabajo tiene sus vueltas.
La pregunta era más que nada para conocer las experiencias de otros. Yo
use las transacciones de varias maneras distintas, la última que
recuerdo, cada Editor tenía su transacción entonces al momento de grabar
los cambios todos los objetos que participaban en el editor eran
enviados dentro de la misma transacción a Omnibase.
También use las transacciones dentro de cada PersistentObject, es decir,
les agregue una transacción a cada uno y sí bien de esa manera era
bastante transparente fue un poco costoso mantenerlas.
Tengo dos formas de trabajar con las transacciones:
Si no tengo concurrencia, si solo un usuario trabajará en una seccion del sistema:
-Entonces le abro una transaccion al usuario, y a medida que hace cambios, le voy haciendo #checkpoint a la transaccion (que es un commit que no cierra la transaccion y te permite seguir laburando)
Si el usuario hiciera un cambio que quisiera deshacer, eso lo manejan mis objetos (Commands), por eso no tengo que hacer #abort.
Si varios usuarios accederán a los datos, el esquema anterior no es factible debido a que mientras la transaccion no haya sido cerrada, los objetos cambiados están bloqueados (LOCKED) y no pueden ser modificados por otros usuarios, a pesar de que el usuario que los modificó ya no los usa más.
En esos casos hago un uso mas sofisticado, y mas desprolijo a mi gusto, de las transacciones.
El usuario trabaja en una transaccion, en la cual selecciona los objetos, elije la forma en que efectuará el cambio en el sistema, etc.
Cuando le da OK a la ventana, se crea una nueva transaccion, se re-levantan los objetos en la nueva transaccion, y se ejecuta la operacion, con su #commit (o su #abort si algo salió mal).
Esta forma de trabajo hace que el tiempo de bloqueo de los objetos, debido a que se está laburando con ellos, sea muy chico, y que no sean tiempos humanos.
La contra es que es mas sofisticado y "sucio" ya que para re-levantar objetos, debo enviar mensajes privados a OmniBase.
Una aclaración importante:
El usuario nunca interactua con los objetos del modelo.
Siempre lo hace con objetos intermedios, que son los Command.
Es decir, cuando un usuario modifica un Cliente, la ventana que levanta es sobre el Command EdicionDeCliente, que copia todos los valores del Cliente, el usuario modifica estas copias, y luego cuando se hace el #commit, el Command se encarga de efectuar esas modificaciones sobre el Cliente original.
Esto es lo que permite que pueda efectuar los cambios propuestos por el usuario en tiempos de maquina y no de humano.
--~--~---------~--~----~------------~-------~--~----~
Ha recibido este mensaje porque está suscrito a Grupos de Google "clubSmalltalk" grupo.
Si quiere publicar en este grupo, mande un correo electrónico a [email protected]
Para anular la suscripción a este grupo, envíe un mensaje a [EMAIL PROTECTED]
Para visualizar más opciones, visite este grupo enhttp://groups.google.com/group/clubSmalltalk
-~----------~----~----~----~------~----~------~--~---
