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 <norbert@hartl.name> wrote:


Am 31.07.2018 um 06:57 schrieb Richard O'Keefe <raoknz@gmail.com>:

Basically, what you are talking about is Software Transactional Memory.
there *is* STM support for Pharo at
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.uhnak@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.
tesonep@gmail.com