Sí, a mí me pasa lo mismo, me gustaría hablar con algunas personas para decirles que están perdiendo su tiempo, pero no creo que me escuchen ;-) Es más, en la práctica se enojan :-(. En la práctica cada uno debe ver dónde lo llevan sus pasos, no es posible traspasar el insight que se le produce a una persona en un área de estudio, para usarlo en otra área de estudio, debe redescubrirlo personalmente, enfrentarse a la pared y darse cabezazos en ella.
Supongo que tiene que ver con el hecho de que hay personas que son visuales, otras auditivas y otras kenestésicas. Las visuales aprenden viendo, con dibujos, colores, etc. Las auditivas tienen que verbalizar y crear o escuchar frases coherentes que les hagan sentido (en Inglés por ejemplo se dice "this is a <<sound>> idea", queriendo decir: esta es una idea <<que me hace sentido>>). Los kenestésicos como tú (y yo en gran medida) necesitan hacer las cosas para entenderlas, se demoran mucho más en entender que los visuales y los auditivos, pero cuando entienden, entienden mucho más profundamente que el resto de las personas. http://www.clinicapsi.com/programacion%20neuroliguistica.html Ahora bien, cuando practicas mucho algún tema con la kenestesia, eventualmente te vuelves visual y auditivo en ese tema, ya que aprendes a reconocer lo que funciona y lo que no, porque lo has hecho muchas veces y a través del trial and error, adquiriste insights que son como actos de magia para el resto. Ok, ese era el análisis de porqué estamos teniendo esta conversación, volviendo a los puntos que mencionas: ¿Quieres realmente tener una transacción en RAM? En principio parecería una buena idea, ya que de esa manera al hacer rollback en la BD también podrías hacer rollback en RAM y no quedarías por ejemplo con cachés con valores equivocados, etc. Además tendrías que usar XA o 2 phase commit para poder hacer participar a la RAM de las transacciones en disco y viceversa. Parece genial tener todo eso resuelto, ¿no? Yo pensaba eso. Pero ya habíamos hablado de que hay objetos que no tiene sentido hacer rollback, por ejemplo objetos que son naturalmente transientes como los sockets. ¿Qué haces ahí? Se me ocurre que habría que registrar objetos transientes y objetos permanentes, de modo que se haga rollback sólo de los objetos permanentes, el resto se desecha de todas maneras (y son los más). ¿Cómo hacemos rollback? Para eso está STM, pero una alternativa simple sería almacenar copias de los objetos antiguos y simplemente volver atrás "transaccionalmente" (== "todos los objetos al mmismo tiempo") ;-) El único problema es que si los objetos son permanentes podemos guardarlos en disco. Este es el mismo problema que sufren los app servers cuando se debe tener la sesión distribuida en un cluster. La idea es que si un usuario se logea en uno de los nodos del cluster, si llega una petición a otro nodo del cluster, éste lo reconozca inmediatamente. Otra solución de más bajo pelo es tener "afinidad" en el cluster, que consiste simplemente en que si te logeaste a traves de la máquina 33, tus peticiones son redireccionadas automáticamente por el load balancer a la máquina 33. Digo que es de bajo pelo, porque si la máquina se cae o se da que justamente las sesiones más largas están en esa máquina, puedo tener 32 máquinas desocupadas y una sobrecargada. Todo eso y además que si se cae la máquina (lo que no sería raro porque le estoy pidiendo mucho, falla un malloc y todo el resto del sistema se viene a abajo), entonces todos los usuarios de esa máquina pierden su sesión. La solución de mayor pelo es que la sesión exista simultáneamente en todas las máquinas (un objeto "persistente"), y si se cae cualquiera de las máquinas, la sesión sigue existiendo. La solución "naive" es tener un objeto en RAM que se replica en todas las máquinas y ocupa RAM en todas las máquinas. De esa manera si una máquina soporta mil usuarios conectados, porque no caben más sesiones en RAM, entonces 10 máquinas, 100 máquinas y mil máquinas soportan exactamente la misma cantidad de usuarios conectados, porque tomé la decisión de tener todo en RAM. Ahora supongamos que decido guardar las sesiones en disco, en la base de datos. Ahora una máquina no tiene límite respecto del número de usuarios conectados, porque de la misma manera que con las URLs una máquina se puede conectar a infinitas otras máquinas simplemente cambiando de URL, un objeto que representa la sesión se puede guardar en arreglos de discos de varios Terabytes. Recursivamente podría armar sistemas tan grandes como quiera. La única tecnología que debo usar para lograr eso son las bases de datos. ¿Ahora qué debo hacer para implementar un base de datos? Puedo implementar SQL en Smalltalk y puedo hacer que ejecute en RAM. Debe sonar medio contradictorio si dije anteriormente que no quiero que ejecute en RAM, pero sígueme la idea. Lo que hacen las bases de datos es tener lo más posible en RAM y sólo escriben en disco en forma "lazy", de modo que tienen todas las ventajas de la RAM (velocidad) y todas las ventajas del disco (persistencia). Respecto de que las variables sean compartidas por 2 threads. Haz la prueba, no funciona. Simplemente lo que pasa en un thread no se ve en el otro. Con una salvedad, si la variable no estaba definida ("accedida") en el thread, entonces el valor puede ser el valor que existe en el otro thread o puede ser un valor local. "It works like a charm." (funciona como por encanto). No le veo problemas a tu diseño de transacciones en AjTalk, lástima que lo vas a implementar a nivel tan bajo, porqué sería genial tenerlo en Smalltalk. De hecho cuando dices "este objeto es transaccional" lo que en realidad estás diciendo es "este objeto es persistente" porque incluso los objetos transientes son parte de la transacción, lo que pasa es que no queda ningún registro de qué valor tenían. (Si el usuario se equivoca y un objeto que debía ser persistente no lo hizo persistente, entonces mala suerte, no hay rollback para él). Por otro lado si meto un objeto dentro de una transacción, pero el objeto no está en disco, se corta la luz y se pierde el objeto de todas maneras. No me parece muy inteligente tener objetos transaccionales que no sean persistentes, porque no encuentro el caso de uso donde se necesite uno y no el otro. Lo que haces de versionar los objetos es un buen insight. Si hay muchas transacciones que tocan los mismos objetos y se bloquean unos a otros (lo que pasa con los threads en C y en Java todo el tiempo), entonces conviene hacer transaccionales los accesos de manera que si una transacción termina, revisa que las variables tengan los valores que ella "modificó" y entonces termina con éxito, si no se deshace de ese "contexto" y o falla o vuelve a empezar. De esa manera si tienes 3 threads que modifican los mismos valores, el primero en terminar tendrá éxito, el segundo fallará porque tocó los mismos valores y el tercero tendrá más oportunidad de terminar exitosamente porque probablemente no alcanzó a leer los cambios causados por el primer thread. Bueno y un contexto es simplemente un dictionary, no debiera ser difícil de implementar ;-) Para implementar transacciones en Smalltalk: ¿No bastaría con crear un proxy transaccional? Digo en vez de modificar los bytecodes, los compiladores, crear una VM nueva (AjTalk), etc. Por lo menos JBoss usa proxies en la implementación de sus EJBs para darles transaccionabilidad. Saludos, Guillermo. On Sun, 2010-10-31 at 07:17 -0300, Angel Java Lopez wrote: > Hola gente! > > Guillermo, muy interesante, pero creo que en alguna parte, nos vamos > del tema de la lista. > > Asi, que comentarios solo sobre lo mas cercano a Smalltalk, que todo > lo que comentas. > > Lo de mantener el valor de una variable en el thread, es lo que hacen > varias implementaciones, como Clojure (y ejem... AjSharpure, > tambien ;-), tema que ya habia enviado, como enlace, en alguno de > estos threads. Apenas una punta en: > http://david-mcneil.com/post/1439050822/clojure-dynamic-variables-and-java-threadlocals > Descripto en mas alto nivel: > http://clojure.org/concurrent_programming > > Parecido a lo que quiero hacer con transaccion: > http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/dosync > Pero opera solo sobre variables del tipo ref. En mi caso, en AjTalk, > sobre objetos transaccionales. Y mi transaccion (sus datos: en que > "tiempo" comenzo, si esta activa, etc...) esta en Thread Local. > > Con respecto a: > Encuentro super raro lo que mandaste respecto de que se requiera tener > en Java un modelo STM ya que en Java el memory model es tal que las > variables no se comparten a menos que explícitamente se utilice > "synchronized"... > > > Hmmm... o sea que toda la gente que esta implementando STM en Java > esta equivocada? :-) :-) Bueno, se lo voy a comentar a Rich Hickey, en > cuanto me lo cruce ;-)... > > Lo que encuentro "super raro" es eso que las "variables no se > comparten". Claro que se comparten en Java. Cualquiera puede ir a una > variable accesible, desde dos threads. No hace falta poner > "synchronized" para compartirlas. > > Volviendo a Smalltalk, quiero explicar por que no sigo tu "approach" > sugerido. Yo quiero llegar, en memoria, en AjTalk (olvidemos base de > datos) a un Isolation de Serialization, por lo menos. Si dos > transacciones tocan el mismo slot (variable de instancia), una no > prosigue. Por que? Porque si T1 trata de cambiar S1 de 100 a 200, y T2 > trata de cambiar al mismo S1 de 100 a 300, puede ser que T2 haya > tomado la decision basandose en varios valores, que leyo hace un > tiempo, tal vez, tambien leyo S1 y lo encontro en 100, hace un tiempo, > y decidio sumarle 200, despues de un tiempo. Se puede proteger mejor a > T2 si al leer S1 con 100, lo lockea. Pero eso implicaria que toda > transaccion LOCKEE cada slot que va leyendo, cuando probablemente > cambie solo algunos, u obligar al programador que ponga explicitamente > que esta haciendo un getInstVarAt: . Y ese lockeo, tan agresivo y > granular, al fin, conspiraria contra la concurrencia. > > Hmmm.. con respecto a tu synchronized... Por lo que entendi, solo > serviria para la variable que declaras como sincronizada. Pero que > pasa si esa variable es anInvoice, y en el bloque modificas algo que > no es slot directo de anInvoice, sino que vas a una lista contenida en > una variable de instancia de anInvoice, que contiene la lista de > renglones, y le cambias esa lista de renglones, o el contenido de un > renglon? > > En mi implementacion, los objetos del dominio, Invoice, Product, > InvoiceProduct, etc... serian transaccionables (por poner un caso, > supongo que en GemStone seria: todos esas clases las manejo en > GemStone: hay que poner en algun momento un "fence" que diga cuales > son los objetos que quiero transaccionar o no, cuales son las clases > que manejo en GemStone y cuales no). O llegado el caso, podria hacer > que todos los objetos sean transaccionales (dudo que lo necesite, pero > puedo hacerlo). > > Un caso de uso: dos agentes (que trabajan en threads diferentes, > procesando mensajes tipo Twitter) quieren modificar una lista de > mensajes entrantes para un tema. En mi implementacion, tanto los > agentes como la lista de mensajes, se declaran explicitamente, los > primeros como agentes (y no simples objetos) y la lista de mensajes > como transaccional (y no simple objeto, donde todos van y le pegan sin > importar la concurrencia). De ahi que no me decante por un > "sincronizame esta variable y hace tal block". Quiero que la lista de > mensajes, sin que el programador tenga que recordar si tiene > concurrencia de agentes o no, siempre funcione como transaccional > dentro de una transaccion. El trabajo para el programador es: declarar > la transaccion, no declarar ni acordarse cuales objetos tiene que > "sincronizar" y cuales no. Lo mismo con agentes: se declaran desde el > principio como agentes, y voila. Ahora tengo una explicacion corta en > Anglish: > http://ajlopez.wordpress.com/2010/10/23/agents-in-ajtalk-introduction/ > > Les debo lo de objetos transaccionales. > > [Atencion: desde el principio de mi propuesta de transacciones (como > supongo que debe pasar en GemStone), el Invoice digamos #12 (si es que > queremos manejar Invoices desde mas de una transaccion, pongo Invoice > como ejemplo, bien podria ser una lista de mensajes de Twitter o lo > que sea que quiera implementar, y que pueda ser consultado, modificado > concurrentemente), reside en memoria con identidad (no hay dos Invoice > #12, digamos). Aclaro esto, porque en otras implementaciones, cuando > un proceso/thread trabaja con el dominio, reificia Invoice #12 en > memoria, desde posiblemente la base de datos, y tiene una copia en > memoria de Invoice#12, mientras otro proceso/thread que justo tambien > quiere trabajar con Invoice#12, se le DA OTRA REIFICACION de esa > factura, al final, ambos hacen commit, y los conflictos se resuelven, > no en la memoria, sino en el sistema de persistencia, 99% de los > casos, la base de datos relacional. No es a estos casos a los que va > apuntado mi intento de objetos transaccionales]. > > En mi implementacion, vigilo los slots de los objetos transaccionales, > en lugar de objetos/variables. Si en la transaccion T1 accedo al > objeto O1 y leo el slot S1, me fijo si hay un valor asignado ya en T1, > sino, tomo el valor que habia en S1 antes de iniciar T1. Podria > mantener los valores cambiados por T1 en el thread actual, pero en mi > implementacion quiero saber si hay otra T2 que modifico a S1 en O1, lo > mas temprano posible (no en el commit). Asi que igual tendria que ver > los valores de otros threads. Solo podria mantener los valores de S1 > en local thread, si difiriera la deteccion de conflictos hasta el > commit. Pero hay sutilezas: una transaccion T1 puede committear sus > valores, pero no puedo poner directamente esos valores en el lugar de > S1 que no es local thread (el valor real, final, global, digamos). Por > que? Porque puede haber transacciones activas que todavia estan > interesadas en el valor que tiene S1 cuando comenzaron. A ver si doy > ejemplo: > > Tiempo 0: S1 tiene 100 (pongamos notacion S1=100/Tiempo 0) > Tiempo 1: T1 comienza > Tiempo 2: S1 tiene 100 (es lo que ve el resto del sistema, con o sin > transaccion) > Tiempo 3: T2 comienza > Tiempo 4: T1 cambia S1 a 200 > Tiempo 5: T1 commitea > Tiempo 6: T2 consulta S1, que le damos? el valor de tiempo 5 (t1 > commiteado? S1=200) o el valor de antes de su comienzo (tiempo 2, S1 = > 100)? > > En mi implementacion, a T2 se le da S1=200/Tiempo 2. T2 ve un > "snapshop" del sistema al momento de iniciarse. Y quiero que sea asi: > todas las decisiones de T2, deberia basarse en un "snapshop" de los > objetos transaccionales que maneje: T2 no puede ver S1 en 100 en un > momento, y S2 en 200 en otro momento de su vida (del lifetime de T2). > > Asi que Tiempo 5, cuando T1 committea, no puedo simplemente poner el > valor GENERAL de S1 en 200 (en Clojure, se llamaria el valor root, en > el codigo fuente de Clojure). Tengo que mantener S1=100/Tiempo 2 hasta > que todas las transacciones interesadas en el valor al tiempo 2 se > terminen. Queda algo como: > > S1=100/Tiempo 2 > S1=200/Tiempo 5 > > Cuando todas las transacciones activas son con tiempo de inicio > 5, o > no hay mas transacciones, paso a: > > S1=200/Tiempo 0 (el valor global, el final, en el objeto O1) > > y aqui no ha pasado nada, muchachos... ;-) > > Nos leemos! > > Angel "Java" Lopez > http://www.ajlopez.com > http://twitter.com/ajlopez > > > 2010/10/31 Guillermo Schwarz <[email protected]> > Angel, > > Claro, la principal razón para querer tener transacciones es > tener > concurrencia, la atomicidad es un "second thought"... sin > embargo es el > "isolated" el que le da la oportunidad de ser concurrente sin > necesidad > de tener que terminar la primera transacción para empezar la > otra. > > En la práctica uno puede hacer las operaciones "locked" tan > pequeñas > como quiera para aumentar la concurrencia (ese es el "insight" > que > utiliza SQL). En otras palabras en vez de hacer "begin tx" = > "begin > lock" y "commit" = "end lock", se agarra cada operación de la > transacción y se hace que tome un "lock" el objeto de la BD > que está > tocando. Aún más, se puede hacer que toda la transacción > trabaje sobre > una copia de la BD y al final cuando se hace commit, se > reemplaza un > puntero con CAS o LL/SC. > > http://www.audiomulch.com/~rossb/code/lockfree/ > > CAS tiene el problema del ABA así que supongo que no es > recomendable. > Acá se explica: > > http://www.audiomulch.com/~rossb/code/lockfree/ > > Y también se da una solución: agregar un contador. > > CAS hace rato que viene implementada en la CPU X86, de modo > que se > podría considerar que es estándar. Pero al parecer tiene bugs: > > https://patchwork.kernel.org/patch/19429/ > > No sé a ustedes pero la impresión que tengo es que tener bugs > a nivel de > la CPU es un "total turn-off". Sin embargo si tenemos un > proyecto ya > metido en esto lo único que queda es detectar en qué CPU > estamos > corriendo y aplicar un workaround en ese caso particular (que > podría ser > tomar objetos más grandes y utiliar locks más grandes). > > Se puede agregar: > > http://phildawes.net/blog/2009/10/13/factor-compiler-adding-instruction/ > > Extraño, no? > > Lo que mencionas de : > > > Algo para leer: > > > > http://doc.akkasource.org/stm-scala > > > > Se contradice un poco con lo que envié yo en algo que > considero > significativo. Lo que envié yo dice que STM a AI, mientras que > tu link > dice que es ACI. > > ¿Porqué? > > Dice ahí que cuando se hace commit de una transacción, la data > de la > transacción se comparte completa con las otras transacciones o > nada. > Para mí eso es Atomic, no Consistent. Consistent como mandé en > el link > significa que existe una metadata que fuerza determinadas > cosas como las > llaves foráneas, de manera que la data sigue siendo > consistente > independiente de las operaciones que haya hecho. > > Por default Smalltalk y cualquier lenguaje no tiene una > metadata que > fuerce las relaciones entre objetos (sí entre objetos y > clases, por > ejemplo un objeto pertenece sólo a una clase). Se podría > pensar que el > sistema de tipos en Java es una forma rudimentaria de > metadata, ya que > si tengo una función con un paŕametro de tipo String no puedo > pasarle un > número y viceversa. Pero las restricciones que puedo poner en > SQL son > mucho más fuertes, parecidas a lo que vendría a ser un sistema > de diseño > por contratos en Eiffel. > > > http://eiffel.com/developers/presentations/dbc/partone/player.html?slide= > > > Encuentro super raro lo que mandaste respecto de que se > requiera tener > en Java un modelo STM ya que en Java el memory model es tal > que las > variables no se comparten a menos que explícitamente se > utilice > "synchronized", lo que se explica en: > > http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html > > En resumen se podría decir que las variables son propias al > thread. Esto > lo he verificado independientemente muchas veces, se debe usar > synchronized. El equivalente en Smalltalk sería decir que > todas las > variables le preguntan al currentProcess (si tal pseudo > variable > existiera) cual es su valor y si retorna nil, entonces recién > le > pregunta a Smalltalk. ¿Qué te parecería esa implementación? El > único > problema que le veo es que nadie usa synchronized en > Smalltalk, pero > supongo que no sería difícil de implementar: > > Process>>synchronize: symbol toExecute: block > Smalltalk at: symbol put: (self at: symbol). > block value > > y se llamaría as: > > currentProcess synchronize: #variable toExecute: [...] > > Como sería muy verboso escribir eso, se podría crear un > método: > > Symbol>>synchronizeOn: block > currentProcess synchronize: self toExecute: block > > Que se invocaría así: > > #variable synchronizeOn: [...] > > Probablemente el cambio más grande sería cambiar el compilador > para que > reconozca currentProcess como una pseudovariable (y sepa a qué > objeto > asociarlo) y que las variables se busquen en currentProcess > antes que en > Smalltalk. > > ¿Qué importancia tiene esto? Que en Java toda la información > se maneja > en forma local en el thread, de modo que no se actualiza al > resto de los > threads a menos que explícitamente se ponga un > "synchronized" (que por > lo tanto es caro, porque cualquier otro thread verá el cambio > SSI hace > "synchronized" sobre el mismo objeto. Buen truco, ¿no? Pero > dado esto, > ¿no estamos a un paso de tener transacciones en memoria? > Synchronized > sería el equivalente a "commit", sólo faltaría implementar el > "rollback" > y da la casualidad que es mucho más fácil, simplemente el > valor que está > en el thread se "bota" y se queda con el valor global. Desde > el punto de > vista del thread basta con copiar el valor de la memoria > global al > thread. > > Por cierto se supone que el Double-checked locking fue > arreglado en Java > 5 cambiando el memory model. Lo verifiqué y al menos en esa > versión > funciona si la variable es "volatile". (Lo mismo ocurre en > Microsoft C > por si acaso ;-). > > Lo chistoso del asunto es que esto resuelve el problema del > double > checked locking: > > public class MyFactory { > private static final MyFactory instance = new MyFactory(); > > public static MyFactory getInstance() { > return instance; > } > > private MyFactory() {} > } > > La razón es que la clase no se va a instanciar 2 veces, por > ende el problema > está resuelto por el class loader. No olvidemos que el > problema original era que > queríamos ejecutar cierto código una sola vez y se nos ocurrió > usar synchronized. > En este caso ejecutamos sólo una vez pero porque Java decide > cargar clase una > sola vez. > > Es bastante interesante Multiverse (bueno es de codehouse.org, > qué se > podría esperar ;-) Al parecer la versión 0.6 no la sacaron en > Junio como > habían planeado. Mirando los "features" de esa versión parece > que tenían > planificado crear bugs en vez de features, ya que si miras lo > que están > planeando implementar no es hacer el código más limpio... pero > bueno, la > idea de STM en general creo que no es muy limpia. Preocupante > es eso de > agregar "delays". En mi experiencia cada vez que alguien > decide "colocar > delays para que el thread tenga más tiempo de ejecutar", es > porque > tenemos problemas serios de "race conditions" y "deadlocks". > > Si tengo "wait-free" y "block-free" data structures se acaban > los > live-locks y los dead-locks. No puedo tener un dead-lock si no > hago > lock. ¿Es obvio no? > > Doug Lea inventó algoritmos concurrentes en Java sin necesidad > de > redefinir el lenguaje ni la JVM: > > > http://books.google.cl/books?id=-x1S4neCSOYC&pg=PA145&lpg=PA145&dq=doug > +lea+wait > > +free&source=bl&ots=Dvhr8_Faw_&sig=ttJpnIRaYniMeFnuw8_wpjqmlW4&hl=es&ei=Zv3MTLOCNoOdlgeJ05CmBg&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBkQ6AEwAA#v=onepage&q&f=false > > Por definición esos objetos podrían participar de algoritmos > distribuidos, con la ínica salvedad a mi parecer que las > estructuras de > datos no son (aun) distribuidas de modo que sería necesaria > que los > proxies hicieran llamadas remotas a donde se encuentran los > objetos > realmente (eso ya lo tienes hecho). Al interior de las JVM > donde esos > objetos residen podrían tener threads modificándolos en forma > concurrente sin problemas. > > Saludos, > Guillermo. > > > On Wed, 2010-10-27 at 10:59 -0300, Angel "Java" Lopez wrote: > > Hola gente! > > > > > > > > STM tiene otro “twist”: la concurrencia. Clojure y otros, > están > > alineados a que haya elementos consumibles concurrentemente. > Por un > > lado, como apuntabas en otro email, con datos inmutables. > Clojure > > tiene toda una serie de estructuras que llaman “Persistent”, > no > > confundir con persistencia en base de datos o similares. Por > otro > > lado, tiene datos mutables, pero vigilados por STM, también > para > > concurrencia. > > > > > > > > Pongo Clojure como ejemplo. El tema a resolver: manejar la > > concurrencia sobre objetos mutables, sin tener que perder el > pelo en > > el intento. Como ya discutimos, otra forma es manejar la > concurrencia > > sin tener mutabilidad, tan afin a programación funcional. > > > > > > > > Algo para leer: > > > > http://doc.akkasource.org/stm-scala > > > > donde aparece Scala (sobre Java) y Akka (excelente proyecto > > distribuido). Ahí hay algunos uses cases, discusión de > persistent > > structures y demás. > > > > Algun experimento de STM que se abandono, pero interesante: > > > > http://channel9.msdn.com/Blogs/Charles/STMNET-Who-What-Why > > > > > > > > Mi idea es reproducir eso en otros ámbitos (lo tengo escrito > y > > publicado), y en particular, ahora, en AjTalk. Por eso > también lo de > > distribuido. Concurrencia y paralelismo, tanto en la misma > maquina, > > como en varias. Conseguir eso sobre una maquina con > multiples core, o > > escalar hacia afuera con varias maquinas. Mis casos de uso > todavía no > > necesitan transacciones, pero lo vi en Clojure y veo que lo > usan. Y > > por lo que lei en GemStone, parece que lo usan, tengo que > preguntar > > por aca algunos temas. Alguna vez llegara a mi un caso de > uso para eso > > (de hecho, pregunte por aca como hacían para manejar la > concurrencia > > sobre objetos en Smalltalk, no parece haber una forma, o no > comentaron > > nada). Tengo otros casos de uso para distribuido, agentes, > acceso > > a .NET o Java nativo, etc, que ya mencione por aca. > > > > > > > > Casos de uso: escalabilidad por concurrencia, sobre dominios > que no es > > importante grabar y tener persistencia al momento, como > servicios > > usados en Farmville, Twitter, etc.. Pero no tengo un caso en > concreto. > > Pero a lo que voy (mas hacia el final) no todo gira > alrededor de una > > base de datos. Notable ejemplo: la imagen de Smalltalk. > Tranquilamente > > puedo trabajar con todo un dominio reificado en la imagen, > ya sea en > > memoria, en disco. > > > > > > > > Entonces, por que ponerlo ahora, esto de objetos > transaccionales? (de > > hecho, escribi por aca hace como 3 semanas, que no estaba > alto en mi > > lista de prioridades) Porque me pareció un “proof of > concept” > > interesante de otra idea: agregar conducta a objetos AjTalk > mediante > > decoradores, tipo el objeto intermedio que comentaba > Mariano. Hoy > > agrego decoradores para conseguir objetos transaccionales. > Ayer, para > > tener objetos distribuidos remotos. Maniana, para conseguir > objetos > > que persistan si no son usados o por otro criterio. > > > > > > > > Persistencia en la base de datos, estará alguna vez, por si > se corta > > la luz ;-) > > > > > > http://msmvps.com/blogs/lopez/archive/2010/08/08/look-ma-no-database.aspx > > > > (donde hay mas indicios para NO ocuparse de la base de datos > ahora, en > > estos temas. El tema nos llevaría a NoSQL y otros temas, que > se alejan > > de esta lista, pero en los que me parece que Smalltalk puede > ir > > montándose tranquilamente, seguramente hay proyectos sobre > eso) > > > > > > > > Un tema que quería contestarle a Mariano: se imaginan una > “maquina > > Smalltalk”, cuyo procesos estén siendo ejecutados en varias > maquinas > > físicas, sin solución de continuidad, todos los > procesadores, toda la > > memoria, como si fueran uno? > > > > > > > > La persistencia estaría dada por la existencia de varias > maquinas, > > quizás distribuidas: se cae una, otra tiene lo que falta, > como en > > varias implementaciones de NoSql. Ver > > > > http://delicious.com/ajlopez/nosql > > > > > > > > Otro punto mas: si tuviera un Sistema Pick, como ya mencione > en otro > > thread, lo de objetos transaccionales bastaría, sin > necesidad de base > > de datos. > > > > > > > > Espero haber dejado varias ideas ligadas a Smalltalk, y no > haberme ido > > demasiado por las ramas, para esta lista. > > > > > > > > Nos leemos! > > > > > > > > Angel “Java” Lopez > > > > http://www.ajlopez.com > > > > http://twitter.com/ajlopez > > > > > > > > > > > > De:[email protected] > > [mailto:[email protected]] En nombre de > Guillermo Schwarz > > Enviado el: Wednesday, October 27, 2010 10:24 AM > > Para: [email protected] > > Asunto: Re: [clubSmalltalk] Objetos Distribuidos > > > > > > > > > > Ángel, > > > > > > > > > > No me parece mal lo de STM, pero no veo la necesidad. > (Alguna vez > > escuché la frase "es una solución en busca de un problema, > en vez de > > un problema en busca de una solución", creo que en esta > ocasión se > > ajusta perfecto al caso). > > > > > > > > > > Primero los objetos deben ser durables, de otra manera ¿para > qué > > modificarlos? Si son transientes son sólo parte de un > mecanismo, no me > > interesa que lo que ve una persona o que modifica, lo pueda > ver > > también otro. IMHO, no tiene senido, a menos que quieras que > hagan > > dibujos en Paint de manera simultánea y luego se borren. > > > > > > > > > > > > Parece más bien un caso particular de "escríbelo en la BD y > luego > > bórralo de manera explícita". Si la disculpa para hacerlo > como lo > > haces es que no quieres que se demore mucho (porque la BD es > lenta) me > > parece que hay usar una BD más rápida. > > > > > > > > > > > > En general si tienes objetos transientes, lo único que > quieres es que > > no se toquen unos a otros, que tengan todo separado de > manera que no > > haya "locking". Eso es lo que hace con los EJBs, todo > separado hasta > > que se llega a la BD que tiene sus propios mecanismos de > resolución y > > si investigas cóm lo hace, tierne más éxito si usa non > locking > > algorithms. > > > > > > > > > > > > ¿Qué estás tratando de resolver realmente? Porque hasta el > momento > > aparte de que es interesante poder lograr lo que has hecho, > me parece > > que cualqueir problema real que podría ser un caso de uso de > usuario > > que podría requerir lo que estás haciendo se puede resolver > de 20 > > maneras diferentes con soluciones que ya están hechas y > probadas. (No > > es por bajar el ánimo, eh? Es sólo tratar de hacer más > fructífero el > > desarrollo). > > > > > > > > > > > > Saludos, > > > > > > Guillermo. > > > > > > > > > > 2010/10/27 Angel Java Lopez <[email protected]> > > > > Hola gente! > > > > Guillermo, el ambito de aplicacion de lo que quiero hacer, > es similar > > al de Software Transactional Memory, donde tambien se > mencionan > > Transactional Objects, no a la de las bases de datos. Una > comparacion > > de los dos ambitos, tomado de un proyecto/ejemplo en .NET: > > > > > > http://weblogs.asp.net/ralfw/archive/2007/07/04/software-transactional-memory-ii-isolation-of-changes-to-transactional-objects.aspx > > > > Mis enlaces > > http://delicious.com/ajlopez/stm > > > > > > > > Nos leemos! > > > > Angel "Java" Lopez > > http://www.ajlopez.com > > http://twitter.com/ajlopez > > > > > > 2010/10/27 Guillermo Schwarz <[email protected]> > > > > > > > > Hola Angel, > > > > creo que se debe aclarar los términos. > > > > En el mundo de las bases de datos relacionales las > > transacciones > > significan ACID: Atomic, Consistent, Isolated y > Durable. > > > > En particular Atomic significa que o se hacen todas > las > > operaciones o no > > se hace ninguna. ¿Cómo implementas eso? No sólo los > objetos > > "transaccionables" deben volver al estado en que > estaban, sino > > que todos > > los qu ehayan sido modificados. Si un objeto no es > durable, > > debiera dar > > lo mismosi se puede devolver a su estado anterior. > Por ejemplo > > un > > socket, si ya envió algo por la red, imposible > "desenviarlo". > > Por eso en > > los EJBs no está permitio conectarse a través de > sockets ni > > escibir > > archivos. > > > > Luego lo de Consistent, no hay manera de hacerlo en > Smalltalk > > a menos > > que modeláramos tablas relacionales en Smalltalk de > modo que > > cada tabla > > fuera por ejemplo un Dictionary (PK -> registro > completo). > > Creo que esto > > hasta el momento no existe. > > > > Luego lo de Isolated, creo que es lo que > implementaste tú, una > > de las > > transacciones falla (y se podría ejecutar de nuevo) > si trata > > de > > modificar un objeto que ha sido modificado en una > transacción > > que aún se > > encuentra activa. > > > > Finalmente lo de Durable correspondería a que el > Dictionary > > que > > representa cada tabla fuera persistente. > > > > No sé si te hace sentido. > > > > Saludos, > > Guillermo. > > > > > > On Tue, 2010-10-26 at 06:17 -0300, Angel Java Lopez > wrote: > > > Hola gente! > > > > > > Interesante el enlace de parallel, gracias > Guillermo. > > > > > > Comentario rapido: el codigo de tarde de domingo, > fue > > agregar > > > transacciones a objetos, en AjTalk. Esta > funcionando, pero > > todavia en > > > revision. Me falta implementar la sintaxis con la > que lo voy > > a usar, > > > pero sera algo como: > > > > > > myObj := MyClass new asTransactionable. > > > > > > "tambien podria poner" > > > > > > MyClass transactionable: true. > > > > > > "y de ahi en mas los objetos creados de MyClass > son > > transactionables". > > > > > > Transaction begin. > > > > > > "modifican los objetos, habra objetos > transaccionables" > > > > > > Transaction commit. "o Transaction rollback" > > > > > > Si dos Process tratan de modificar la misma > variable de > > instancia de > > > myObj, uno dara exception. Me falta controlar las > variables > > indexadas. > > > > > > Nos leemos! > > > > > > Angel "Java" Lopez > > > http://www.ajlopez.com > > > http://twitter.com/ajlopez > > > > > > 2010/10/26 Guillermo Schwarz > <[email protected]> > > > Sí, bueno, yo veo que todo tiende a Java, > a pesar de > > que los > > > lenguajes > > > funcionales (F#) parecen estar mejor > implementados > > en .NET que > > > en la JVM > > > (Scala y Clojure). > > > > > > Y me gustó la idea de implementar EJBs en > Smalltalk, > > por > > > alguna razón > > > imagino que es un buen vehículo conceptual > que > > existan threads > > > con > > > transacciones en vez de threads con locks. > > > > > > Y de esa manera las bases de datos > resuelven el tema > > de las > > > transacciones, el código en Smalltalk > simplemente > > indica en > > > qué momento > > > gatillar el "commit". > > > > > > Entonces estará el problema de cómo hacer > las > > transacciones a > > > la base de > > > datos si según recuerdo no existe una > manera > > estándar como > > > JDBC para > > > acceeder a las BDR desde Smalltalk. > Entonces me topé > > con > > > TOPLink, que al > > > parecer es sólo abierto en el caso de Java > y con > > Glorp, que al > > > parecer > > > es el estándar hoy en día en el mundo > Smalltalk: > > > > > > http://www.glorp.org/ > > > > > > Entonces una vez implementada la > persistencia > > mediante Glorp, > > > debiera > > > poder delimitar transacciones a través de > EJBs y la > > ejecución > > > a través > > > de [] fork debiera ser trivial... > > > > > > Al menos conceptualmente me parece que la > solución > > anda, no sé > > > tú. ¿Te > > > suena a que anda? > > > > > > ¿Porqué digo esto? Porque me topé con > esto: > > > http://wiki.squeak.org/squeak/537 > > > > > > Lo que me parece que estuvieran tratando > de replicar > > son los > > > ambientes > > > Lisp distribuidos en los que funciona de > manera > > trivial el > > > paralelismo > > > masivo porque en Lisp casi no hay nada > compartido. > > Lograr eso > > > en > > > Smalltalk creo que es casi imposible, > porque el > > lenguaje está > > > pensado > > > para que modifique el estado de los > objetos en > > memoria. El > > > enfoque que > > > yo tengo es que sea responsabilidad del > programador > > no hacer > > > ninguna > > > llamada a objetos en memoria, lo mismo que > pasa con > > los EJBs > > > en Java. > > > > > > Ahora como estos EJBs están en Smalltalk > en realidad > > debieran > > > llamarse > > > EOB (Enterprise OBjects). > > > > > > Saludos, > > > Guillermo. > > > > > > > > > > > > On Tue, 2010-10-19 at 18:26 -0300, Angel > Java Lopez > > wrote: > > > > Comentario corto: Hace unos anios > comence a > > escribir este > > > tipo de pet > > > > project, en C#, porque no estaba claro > que pasaba > > con un > > > Java VM o JDK > > > > Abierto. Ahora esta el Harmony de > Apache, que > > recuerde. Pero > > > ya casi > > > > desde principios de siglo, tenemos Mono. > No probe > > todo lo > > > que escribo, > > > > pero un pet project bastante importante > para mi, > > que esta > > > siendo usado > > > > diaramente en dos proyectos de > desarrollo, corre > > sin tocar > > > nada, desde > > > > el compilado, en Ubuntu con Mono, y en > OS/X de Mac > > con Mono. > > > > > > > > Y esta todo el codigo fuente de Mono > para ese > > soporte. > > > > > > > > Nos leemos! > > > > > > > > Angel "Java" Lopez > > > > http://www.ajlopez.com > > > > http://twitter.com/ajlopez > > > > > > > > 2010/10/19 Guillermo Schwarz > > <[email protected]> > > > > > > > > > > > > Quizás lo que > quiere > > Valluod es > > > desligarse de > > > > una plataforma > (C#) de la > > que no > > > tiene los > > > > fuentes ;-) > > > > > > > > Lo que? > > > > > > > > > > > > Me refería al codigo fuente de > c#. > > > > > > > > Si el día de mañana sacan > Windows 9 u 8 y > > sobre el > > > corre > > > > solo .net 9 u 8, pero tu vm no > corre sobre > > el nuevo > > > runtime, > > > > perdiste toda la inversión de > tiempo que > > hiciste. > > > > > > > > Mientras que si desarrollas > sobre una > > plataforma > > > open source, > > > > no importa lo que cambien por > debajo, > > siempre puedes > > > adaptar > > > > tu plataforma porque dispones > del código > > fuente. > > > > > > > > > > > > > > > > > > > > > > > > Andres. > > > > > > > > > > > > > > > > > > > -- > > > > > > > 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 > > 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 > 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 > > > > > > > > > > > > -- > > Saludos cordiales, > > > > Guillermo Schwarz > > Sun Certified Enterprise Architect > > > > > > -- > > 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 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
