Transacciones de Objetos

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Transacciones de Objetos

Angel Java Lopez
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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Transacciones de Objetos

Andres Valloud-5
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 <[hidden email]>:

> 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 [hidden email]
> To unsubscribe from this group, send email to
> [hidden email]
>
> http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Transacciones de Objetos

Angel Java Lopez
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 <[hidden email]>
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 <[hidden email]>:
> 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 [hidden email]
> To unsubscribe from this group, send email to
> [hidden email]
>
> http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Transacciones de Objetos

Guillermo Schwarz
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 <[hidden email]>
>         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 <[hidden email]>:
>        
>         > 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
>         [hidden email]
>         > To unsubscribe from this group, send email to
>         > [hidden email]
>         >
>         > http://www.clubSmalltalk.org
>        
>         --
>         To post to this group, send email to
>         [hidden email]
>         To unsubscribe from this group, send email to clubSmalltalk
>         +[hidden email]
>        
>         http://www.clubSmalltalk.org
>
>
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to clubSmalltalk
> +[hidden email]
>  
> http://www.clubSmalltalk.org

--
Simplex Veri Sigillum

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Transacciones de Objetos

Angel Java Lopez
Hola gente!

Guillermo, gracias por la info, si, se entendio perfectamente.

Bien, yo voy a implementar la 2. Algo ya tengo en:

<WARNING>C# CODE INCLUDED</WARNING> ;-);-);-)
http://code.google.com/p/ajcodekatas/source/browse/trunk/AjLanguage/Src/AjLanguage/Transactions/Transaction.cs

con algo como numeros de version. Eso esta implementado para otro interprete, donde no todos los objetos son transaccionales, solo los que se marcan explicitamente, o los que derivan de clases marcadas como transaccionales.

Mi idea es implementar eso en AjTalk, de forma transparente, incluso mejor que ahi. Por ejemplo, sea un objeto, un slot (variable de instancia, indexada) y un valor:

slot --> valor

Cuando consulto el slot, tomo el valor. Pero si trabajo con transacciones, el slot ese evolucionara a:

slot --> XValor(valor1:tiempo1, valor2:tiempo2 ...)

Eso, solamente en los slots que fueron CAMBIADOS por transacciones. Cuando un proceso en la transaccion T1, se interesa solo por los valores que existian al momento de su creacion. Mi bytecode de "tomar el valor del slot" se daria cuenta: "oia, aca hay un XValue, tonche, estoy en T1, tomo solo, digamos, valor1". Mi bytecode de "poner valor en el slot" se encargaria de armar, alguna vez, el XValor si esta funcionando con transacciones.

En mi implementacion, SOLO UNO de los valorn, seria un valor seteado por una transaccion activa. Si otra transaccion activa trata de poner un valor nuevo, se la rechaza, exception.

Entonces, por que tener varios valorn? Porque puede que algunos de esos valores son valores de transacciones YA committeadas, digamos, en tiempo3, pero todavia hay transacciones que necesitan los valores de tiempo1, porque mi implementacion elige darle a una transaccion los valores al momento de su nacimiento, sin importar si luego esos valores fueron cambiadas por transacciones ya committeadas (hmmm.. debe ser in Isolation Snapshot o Serializable en el mundo de base de datos, no recuerdo).

Lo que no puede haber es dos transacciones en curso, que haya seteado dos valores distintos para el mismo slot.

Los XValue se van depurando con el tiempo, tengo varias estrategias a analizar.

(si se atreven a ver codigo C#, en varios puntos trato de no lockear, sino de usar InterlockedIncrement y otros asi, mas livianos; pero si, en primera aproximacion, tengo que hacer que algo ande, pongo lock, mas adelante, refactorizar).

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez


2010/10/13 Guillermo Schwarz <[hidden email]>
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 <[hidden email]>
>         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 <[hidden email]>:
>
>         > 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
>         [hidden email]
>         > To unsubscribe from this group, send email to
>         > [hidden email]
>         >
>         > http://www.clubSmalltalk.org
>
>         --
>         To post to this group, send email to
>         [hidden email]
>         To unsubscribe from this group, send email to clubSmalltalk
>         +[hidden email]
>
>         http://www.clubSmalltalk.org
>
>
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to clubSmalltalk
> +[hidden email]
>
> http://www.clubSmalltalk.org

--
Simplex Veri Sigillum

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org