Transacciones de Objetos
Locked
 
|
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 |
Re: Transacciones de Objetos
|
|
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 |
Re: Transacciones de Objetos
|
|
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... -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Transacciones de Objetos
|
|
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 |
Re: Transacciones de Objetos
|
|
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 -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
«
Return to Español (Spanish)
|
1 view|%1 views
| Free forum by Nabble | Edit this page |