Ticket #181 (closed defect: fixed)
Opened 9 years ago
Updates for locally dead objects cause inconsistencies
| Reported by: | Bernhard Haumacher (haui at haumacher dot de) | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 2.0 |
| Component: | uka.karo | Version: | |
| Severity: | normal | Keywords: | |
| Cc: |
Description
The solution to garbage collection within a replicate object graph (ticket:207) describes an approach that allows to cope with arriving patches for locally dead objects. Those patches can occur, because an object may die at any time, and the local node may have no chance to announce that it has no longer a copy of a particular object. The solution suggested was to apply an arriving patch for a locally dead object to its surviving backup copy, and only revive the object itself (by cloning its backup copy), if a reference to the object is received that may reenter the object to the reference graph of the replicated object.
Unfortunately, this approach is broken, because the following might (and does) happen: An object A dies locally on node #0, just before node #1 sends a patch for this object. This patch is applied on node #0 to the surviving backup copy A' of object A. The patch adds a reference to object B, which is new to node #0 and is therefore marshaled along with the patch. But the object B contains a reference back to object A. While unmarshaling B, the object A must be revived by cloning its backup copy and reentering this fresh local version of A to the local object table. Unfortunately, this reviving of object A occurs during the application of the patch to its backup copy A'. If the patch contains more state updates than the introduction of the new reference to B, this update is only applied to the backup copy A' of A. This inconsistency on node #0 is fixed during the next update and marshaled back to node #1, where a part of the last modification is reverted. Magically, this patch is received from a dead object on node #0.
In combination with merge annotations according to ticket:179, another problem occurs. Since the patch method takes two parameters (the original and its backup copy), both of them pointed to the same object in case of receiving a patch for a locally dead object. If no special care is take when applying incremental updates, the update is applied twice (to the original and its backup copy, which actually point to the same object).
Solution: Eagerly reviving objects
When eagerly reviving locally dead objects (at the time a patch for them is received), both problems described above will dissappear. But this approach increases the danger of object thrashing.
fixed since 1.08b.
