Possible to lose modifications through concurrent operations
If multiple Smalltalk Processes concurrently manipulate the samereplicate, it is possible for a change to that replicate to be
lost. For this to happen, specific circumstances must be occur in a
quite narrow time window.
Specific circumstances:
In most versions of GBS, if one Process modifies a replicate while
another process is making the replicate into a stub, the modification
can be lost. Replicates become stubs due to either an explicit request
or as the result of server execution if the object has changed on the
server and its fault policy is #lazy.
In a few versions of GBS, if one Process modifies a replicate while
another Process is initiating server execution, the modification can
be lost.
When using the GBS automatic dirty-marking feature in VA Smalltalk and
VisualWorks 7.x, it is possible for GBS to make these failures
impossible. In VisualWorks 5i, making automatic dirty-marking immune
to these failures would slow execution down, so we do not anticipate
ever fixing this problem in VisualWorks 5i.
All applications which manually mark objects dirty are vulnerable to
this problem.
We recommend that all customers use VisualWorks 7.x or VA Smalltalk,
and that that their applications use automatic dirty-marking. If you
must use VisualWorks 5i or manual dirty-marking, the application must
be very careful when accessing sessions and their replicates from more
than one Smalltalk Process.
Workaround:
No workaround