Hello, A lot of time ago, we have implemented a basic support for STM in Java (it is written in Scala... dark dark dark ages). We have used aspect oriented programming to intercept the reading and writing of the instance variables of the classes that support the transactions. We kept a dictionary with the values for the transactions in course and a version, and the original object has the "commited" values. On a commit you can apply the changes to the object iff there is no conflict version.
I think a similar implementation could be done in Pharo using Slots in a couple of hours. Also, you should use process specific values to detect and handle in witch transaction you are. Depending how much you want to guarantee ACID properties, you will have simpler or complex implementation. In those days, we only wanted only isolation. Sadly, the details of the implementation are in a Master Thesis in Spanish, I doubt they will be useful, but still I can point you to the source code of the solution. By the way, this is still in use as a part of a tool to teach UI design. https://github.com/uqbar-project/arena/tree/master/arena-pot Cheers, Pablo On Tue, Jul 31, 2018 at 8:48 AM Norbert Hartl <norb...@hartl.name> wrote: > > > Am 31.07.2018 um 06:57 schrieb Richard O'Keefe <rao...@gmail.com>: > > Basically, what you are talking about is Software Transactional Memory. > According to > https://en.wikipedia.org/wiki/Software_transactional_memory#Smalltalk > there *is* STM support for Pharo at > http://source.lukas-renggli.ch/transactional/ > although the last version there is from 2012, and there have been major > changes to Pharo > since then, so it probably doesn't work any longer. > > You could probably make a TransactionalObject class with a > 'lastTransaction' > instance variable, and a noteChange method that checks if lastTransaction > == > Transaction current, and if not, pushes self -> self shallowCopy onto a > stack > inside Transaction and sets lastTransaction to Transaction current. Then > to > roll back a transaction, peel back original -> backup records from the > stack > and do original copyFrom: backup for each of them. > > Please don't ask me to think about combining this with concurrency. > > You could delegate the transaction list and other objects to a process > specific variable. But the biggest problem with a copy approach is that all > identity checks fail with the copied objects > > Norbert > > On 31 July 2018 at 01:16, Peter Uhnák <i.uh...@gmail.com> wrote: > >> Hi, >> >> is there some library or approach how to do transactions in pharo? >> And I don't mean database transactions, but directly in memory on Pharo >> objects... e.g. >> >> p := Person new. >> >> transaction do: [ >> p name: 'Nobody'. >> p age: 70. >> ] on: Error do: [ >> transaction rollback. >> ]. >> >> self assert: p name equals: 'Nobody'. >> self assert: p age equals: 70. >> >> transaction do: [ >> p name: 'Somebody'. >> p age: 1 / 0. >> ] on: Error do: [ >> transaction rollback. >> ]. >> >> self assert: p name equals: 'Nobody'. >> self assert: p age equals: 70. >> >> Any pointers appreciated. >> >> Thanks, >> Peter >> > > -- Pablo Tesone. teso...@gmail.com
