Project

General

Profile

Bug #9274

Analyze how creatingBuffer is relevant after the introduction of multiplyReferenced DMOs

Added by Alexandru Lungu over 1 year ago. Updated over 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

History

#1 Updated by Alexandru Lungu over 1 year ago

This task is about the relevance of RecordBuffer.creatingBuffer.

Recently, FWD added support for multiplyReferenced DMOs, that are DMOs referenced by multiple buffers at the same time. The idea here is that a buffer that runs out of scope may not flush the DMO if it is multiply referenced. This breaks an invariant used in the design of creatingBuffer (aka there is only one buffer that is responsible of a transient record). In fact, the creatingBuffer can become unavailable, because after creation, the DMO can be loaded in another buffer and the OG creating buffer run out of scope. This basically means that the creatingBuffer will become unavailable and much logic related to RecordBuffer.creatingBuffer doesn't consider that.

Although the concept is flawed by design, I think we can resurrect this creatingBuffer by switching it to an arbitrary buffer that still holds that record. My idea is that a RecordNuffer.getCreatingBuffer should be used to resolute either the "cached" creatingBuffer, or if it is unavailable, look-up for another buffer that has the exact same DMO already loaded and presume it is the "creating buffer". In short words: automatically switch the "creating buffer" if needed.

The issue derived from #9050, where the RecordNursery is incorrectly caching the DMO with its creating buffer, unkowning that the creating buffer can become unavailable. In that case, the DMO still should have been flushed/registered to the dirty database if multiply-referenced.

Class-specific:
  • RecordBuffer should use a .getCreatingBuffer logic that does the automatic look-up
  • RecordNursery - #9050 WIP
  • DirtyShareContext - not very relevant if they keep referencing a stale buffer - we need just the DMOBufIface and multiplex to reckon what persistence do we actually need. These two classes do not require internal logic with buffers; is just a place we make such mapping and the consumer (which is usually the Record Buffer) should resolute the buffer better.

Further insights on creatingBuffer are much appreciated.

Also available in: Atom PDF