Project

General

Profile

Support #10226

« Previous | Next »

Consider creating one single dirty-share database per session to support intra-session cases

Added by Alexandru Lungu about 1 year ago. Updated about 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 about 1 year ago

  • Tracker changed from Bug to Support

Similar to #10222, I think that DefaultDirtyShareManager is still able to leak records in between sessions. I am not 100% sure, but according to my static analysis, it is possible.

  • session 1 creates a record and forces it to go into the intra-session dirty-share database.
  • session 2 create a record and forced it to go into the intra-session dirty-share.
  • session 2 does a FIND FIRST. It is honoring the dirty-share database, so it theoretically can find the record of the first session, presuming it has precedence on the index.

I am aware that we can disable cross-session dirty share, but the fact that records are stored into a database without a discriminator makes me wonder if a session can really understand if the "seen" record is bound to its session or not.
I have this into support for further investigation. Maybe there are some in-memory collections that rule-out this possibility, like checking if the record recid is inside a specific collection and thus moves to the next record.

I think it is worth double-checking.

Also available in: Atom PDF