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 [email protected] http://www.clubSmalltalk.org
