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,