Hola Sergio Muy interesantes los comentarios.
>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. Claro, yo use está forma porque no conocía los checkPoint. También me parece un poco más engorrosa que la otra, pero me funcionó perfectamente hasta ahora [*] . Voy a probar con los CheckPoint porque me parece una buena y hasta quizas un mejor uso de las transacciones. Vos usas omnibase en alguna aplicación en producción ? Alguna vez te quedo corrupta una base por algun motivo ? Hasta ahora lo unico que me da "miedo" es no saber sobre si escala con muchos objetos. Digo, que va a pasar después de 3 o 4 años de uso del sistema ?. Existen herramientas de reparación por si la base quedara corrupta o voy a tener que hacerlo desde la copia de seguridad ? Saludos, Facundo [1] Es una app. chiquita, que reemplaza unos macros de excel, debe tener unos 3 mil objetos (pedidos). Sergio Fedi escribió: > > 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 -~----------~----~----~----~------~----~------~--~---
