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