Feature #7964
investigate the benefits of disabling cross-session features of the dirty share database (without completely eliminating all dirty share functionality)
0%
Related issues
History
#1 Updated by Greg Shah 6 months ago
- Related to Support #7963: disable dirty share database and test existing customer applications added
#2 Updated by Greg Shah 6 months ago
- Related to Feature #7037: remove dirty share manager added
#3 Updated by Greg Shah 6 months ago
When we removed Hibernate (#4011), we implemented the record nursery which was meant to be a more efficient way to manage unflushed new records. The integration of these records into FIND query results required the dirty share database. These features have implications for single-session unflushed new records which is a different problem than the original cross-session case that was the original point of the dirty share database. The problem here is that the dirty share is costly (and nasty) and we really don't want it running.
If an application needs this for even single-session usage, then we would pull in all dirty share processing even though some amount of it is never used. This task is meant to determine if the cross-session aspects (locking/synchronization...) can offer a performance benefit if they are disabled by configuration in applications that don't need it BUT which do need the single-session record nursery capability.