ok, las transacciones fueron inventadas en el mundo de las bases de
datos y por lo tanto hay que mirar ahí cómo lo resolvieron.
Según mi particular y peculiar punto de vista sólo hay 2 opciones
posibles:
1. 2 threads ejecutan simultáneamente código y van "bloqueando" todos
los objetos que tocan de modo que si otro objeto ya bloqueado es tocado
por otro thread (en otra transacción, obviamente) entonces el thread
ahora es que el se bloquea hasta que la primera transacción termine.
Y como en smalltalk hay métodos inspectores y mutadores, 2 inspectores
no se bloquean, 2 mutadores sí, un mutador y un inspector también (sobre
el mismo objeto). Recordar que esto es por objeto porque es el objeto el
que debe ser coherente...
Ahora bien puedo tener 3 cuentas corrientes: A, B y C, si traspaso de la
A a la B 10 mil pesos y de la A a la C 50 mil, pero en la cuenta A sólo
tengo 55 mil, ¿cómo me aseguro que se haga una u otra transacción, pero
no las 2 y aún más importante, que no se cree ni desaparezca dinero en
la transacción?
AccountManager>>moveFrom: accountFrom to: accountTo amount: anAmount
TransactionManager begin.
accountFrom amountAdd: - anAmount.
accountTo amountAdd: anAmount.
TransactionManager commit
Entonces se llama así:
[ AccountManager new moveFrom: a to: b amount: 10000.] fork
[ AccountManager new moveFrom: a to: c amount: 50000.] fork
Luego en a puede haber 5 mil o 45 mil.
Tarea: Implementar TransactionManager ;-)x
2. La segunda solución consiste en que cada objeto tiene un número de
versión y hay un número global que indica el número de transacción que
está ejecutando, de modo que cada transacción va modificando el valor de
versión de cada objeto que lee o modifica con el número de la tx, y el
sistema mantiene una lista de las transacciones activas, de modo que si
una transacción va a tocar un objeto que tiene un número más nuevo,
entonces sólo ve las versiones más antiguas. En otras palabras, nada se
bloquea, a menos que lleguen 2 threads que desean mutar el mismo objeto,
en cuyo caso la segunda transacción falla y se reintenta después (eso es
opcional).
Esto se llama lock free algorithms.
¿Se entendió?
Saludos,
Guillermo.
On Tue, 2010-10-12 at 13:53 -0300, Angel Java Lopez wrote:
> Hola gente!
>
> Gracias Andres, por las pistas. Y con lo que comentas, empiezo a
> entender el manejo de GemStone con los conflictos entre transacciones.
>
> A ver si pongo explicito a que objetos me referia ... yo me referia a
> transacciones en TODOS los objetos que toca un Process, desde que T1
> comienza, hasta que T1 hace "commit" o "rollback".
>
> No hablo de "repositorio" y "copia local", que, no se si entendi bien
> tu expresion, me sugiere "copia local" aca en esta VM, "repositorio"
> alla lejos, en otra maquina especial, VM GemStone y similar. Exclui
> expresamente el tema de GemStone o similares, en mi email, limitandome
> a una VM, solita, corriendo en el medio de las pampas ... ;-).
>
> Puedo implementar lo que describi, sin recurrir a "repositorio" ni
> "copia local". Simplemente cambiando la implementacion del bytecode
> "dame el valor de tal variable de instancia", del bytecode "dame el
> valor de tal variable de instancia" y algun otro bytecode, eso si, con
> un poco de trabajo, paciencia y saliva... ;-). Pero antes de encararlo
> (que no esta en mi prioridad alta), me gustaria saber si ha tenido
> algun uso asi en Smalltalk, o si hay alguna libreria que montada sobre
> un Smalltalk (insisto, VM tranquila, aislada, solita y sola) logre ese
> efecto?
>
> Tal vez me respondan: "No, nunca en la historia necesitamos eso,
> cuando lo necesitamos fue cuando DOS procesos, en DOS maquinas
> distitnas, acceden a los mismos objetos, ALMACENADOS en un tercer
> lugar, un repositorio, tal como lo resuelve GemStone". No me queda
> claro si esa es la respuesta a la que apunta el bueno de Valloud.
>
> Como manejan, en general, en Smalltalk, el caso de DOS procesos en UNA
> VM, ambos accediendo a los mismos objetos?
>
> Esa descripcion de transacciones que hice, tiene uso en Smalltalk? hay
> alguna implementacion asi? He visto algo asi en Clojure (Lisp
> implementado sobre Java VM, con varias cosas adicionales, como esto de
> Software Transactional Memory).
>
> No se, no me quedo claro que GemStone funcione asi (localmente).
> Pregunta: GemStone se puede montar sobre una VM aislada y funcionar
> dando transacciones en memoria sobre objetos de esa VM? Siempre que me
> fije, me parecio como que GemStone trabaja en sus propios nodos, y con
> distintos Smalltalks uno trabaja contra esos nodos GemStone. Pero
> puede que haya entendido mal a GemStone.
>
> Nos leemos!
>
> Angel "Java" Lopez
> http://www.ajlopez.com/
> http://twitter.com/ajlopez
>
>
>
> 2010/10/12 Andres Valloud <[email protected]>
> Yh... que se puede decir que no se haya dicho ya acerca de...
> eh...
> una musica...
>
> Eso que decis de transacciones me parece que tiene sentido si
> primero
> se define que es lo que cambia mediante una transaccion. Asi
> como
> pones el ejemplo no esta explicito cual es el conjunto de
> objetos
> sobre el cual se basa la transaccion (o sea, el cuerpo de
> objetos
> subordinados al regimen de transacciones).
>
> Esas preguntas que haces las responde todas GemStone... no
> pasa nada
> si T2 hace cosas en su copia local de aRect. Pero cuando
> intenta
> hacer commit, el commit rebota porque el objeto cambio desde
> la ultima
> vez que T2 miro a aRect en el "repositorio". Ahi T2 tiene
> varias
> opciones... hacer un abort para obtener una nueva copia de
> aRect (y
> tal vez volver a cambiar a aRect y ahi hacer un commit), o
> hacer
> commit igual a lo bruto, etc... la utilidad de cada
> alternativa
> depende de la aplicacion.
>
> Asi a primera vista, me parece dificil implementar esto de
> manera
> general sin una division clara entre "repositorio" y "copia
> local".
> Por ejemplo, que quiere decir que una transaccion local vaya y
> cambie
> el regimen de transacciones para todos los demas? Siendo que
> en una
> imagen vale obtener referencias a cualquier objeto, como se
> hace
> exactamente para imponer alguna frontera mas o menos segura
> entre los
> objetos transaccionados y el resto? Asi con las imagenes que
> tenemos
> hoy, no se.
>
> Andres.
>
> 2010/10/12 Angel Java Lopez <[email protected]>:
>
> > Hola gente!
> >
> > Ayer, el bueno de Valloud menciono transacciones, imagino
> transacciones de
> > objetos. Menciono tambien GemStone. Antes de preguntar sobre
> GemStone,
> > quisiera preguntar algo sobre Smalltalk en general.
> >
> > Que consideran como transacciones de objetos, aca, en
> Smalltalk? En lo que
> > viene abajo, no hablo de distribuido, simplemente
> transacciones en una VM
> > digamos local.
> >
> > Me imagino:
> >
> > aRect := Rectangle new.
> >
> > En algun momento
> >
> > aRect width: 100.
> >
> > En un proceso P1, se arma una transaccion T1 (no se si esto
> existe en lo que
> > llaman por aca transacciones).
> >
> > Un poco mas adelante, en un proceso P2, se arma una
> transaccion T2.
> >
> > Durante T1, la evaluacion de:
> >
> > aRect width
> >
> > devuelve 100. Lo mismo en T2.
> >
> > En algun momento, T1 hace
> >
> > aRect witdh: 200
> >
> > con lo que se cambia algun estado interno, supongamos una
> variable de
> > instancia width. Todavia no hace T1 commit.
> >
> > Luego de ese instante, en T2 se evalua
> >
> > aRect width
> >
> > y sigue dando 100 (aca asumo que T2 siempre ve una especie
> de snapshot de lo
> > que tenian los objetos al comienzo de la vida de T2, y por
> supuesto, ve los
> > cambios que hace T2, pero no los de otras Tn).
> >
> > T1 hace commit. T2 sigue funcionando.
> >
> > Aparece en algun proceso P3, una transaccion T3, nacida
> luego de T1 commit.
> > En esa T3, el evaluar
> >
> > aRect width
> >
> > devuelve 200, de acuerdo a los valores YA committeados por
> T1. Mientras
> > tanteo, en T2 sigue siendo
> >
> > aRect width
> >
> > valiendo 100, segun lo que habia al comienzo de T2.
> >
> > Que pasa cuando T2 hace:
> >
> > aRect width: 300
> >
> > ? Da error ahi? Da error mas adelante, cuando hace commit y
> se ve que algun
> > cambio de estado esta en conflicto con lo que ya committeo
> T1? Gana
> > simplemente T2?
> >
> > Es esto que describo arriba, lo que llaman por aca
> transacciones de objetos?
> >
> > Existe esto en algun Smalltalk? (recuerden, estoy
> considerando NO objetos
> > distribuidos, sino cambios en la memoria de una simple VM
> local).
> >
> > Bueno, esas son mis preguntas, cualquier info, bienvenida y
> se agradece!
> >
> > Algo implemente en [1], y queria pasar a implementar algo
> similar en [2], mi
> > pet project. La idea seria tener algo como Software
> Transactional Memory
> > (mis enlaces http://delicious.com/ajlopez/stm)
> >
> > Nos leemos!
> >
> > [1]
> >
>
> http://ajlopez.wordpress.com/2010/06/07/memory-transactions-in-ajsharp-using-references/
> > [2] http://code.google.com/p/ajtalk/
> >
> > Angel "Java" Lopez
> > http://www.ajlopez.com
> > http://twitter.com/ajlopez
> >
>
> > --
> > To post to this group, send email to
> [email protected]
> > To unsubscribe from this group, send email to
> > [email protected]
> >
> > http://www.clubSmalltalk.org
>
> --
> To post to this group, send email to
> [email protected]
> To unsubscribe from this group, send email to clubSmalltalk
> [email protected]
>
> http://www.clubSmalltalk.org
>
>
>
> --
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to clubSmalltalk
> [email protected]
>
> http://www.clubSmalltalk.org
--
Simplex Veri Sigillum
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
http://www.clubSmalltalk.org
