Well...there is when you find out that simple persistency solutions may start being a problem for you. Most of the times is as Joachim says, that is, the synchronism of data is managed by the persistency solution. Could be mongo (but I never tried with multiple images), could be Glorp, GemStone, Magma, etc.
I the last years I've been doing the "develop on Pharo and deploy on GemStone" and I am very very happy with it. GemStone does have quite some tools to reduce even more the commit conflicts. For example, it provides "Reduced Conflicts" collection classes, that for example allow concurrent adding/removing/iteration things (depending on which class) from multiple VMs... It also provides locks you can manually ask/release, thought this is not common. In addition, the GLASS version of GemStone and the port of Seaside comes with a very very simply approach in which at the start of a request, a GemStone session is opened. At the end of the request, it tries to commit. If there was a conflict, it rollbacks and then tries again. 3 times. This solves quite some scenarios of typical "commit conflicts" that could be solved automatically by just waiting a little bit and re-try. So... if you are willing to spend some hours to lear about GemStone, I would give that a try. Cheers, On Tue, Aug 4, 2015 at 7:54 AM, Sean P. DeNigris <s...@clipperadams.com> wrote: > When using any tool that exposes objects outside the image - Seaside, > Amber, > rST - how does one guard against simultaneous edits? Up until now, I've > been > perfectly content with single images and read-only web apps, but now that > I'm considering some stateful web apps/services, I can't remember ever > seeing locking addressed. And I wonder if all the cool new JS technology > could make the process more responsive i.e. notify the client if the > underlying data has changed... > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Sharing-Inter-image-Data-tp4840912.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com
