You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It appears that ERXObjectStoreCoordinatorPool leaks EODatabase._DatabaseRecord objects whenever the pool size is > 1 and EOs are saved. After many hours in the debugger, I think I understand why...
Normally, when an EC saves changes, the ObjectsChangedInStore notification is fired, the snapshot is inserted with EODatabase's _fastHashInsert and then the EC refaults the EO when processing changes (updates) or frees the snapshot on finalize (inserts). These actions fire the corresponding _fastHashRemove to free the snapshot.
The problem appears to be that ERXObjectStoreCoordinatorSynchronizer rebroadcasts the ObjectChangedInStore notification to the other OSCs in the pool. This results in snapshots inserted, but with no EC around to clean up, the snapshots are never removed.
The text was updated successfully, but these errors were encountered:
It appears that ERXObjectStoreCoordinatorPool leaks EODatabase._DatabaseRecord objects whenever the pool size is > 1 and EOs are saved. After many hours in the debugger, I think I understand why...
Normally, when an EC saves changes, the ObjectsChangedInStore notification is fired, the snapshot is inserted with EODatabase's _fastHashInsert and then the EC refaults the EO when processing changes (updates) or frees the snapshot on finalize (inserts). These actions fire the corresponding _fastHashRemove to free the snapshot.
The problem appears to be that ERXObjectStoreCoordinatorSynchronizer rebroadcasts the ObjectChangedInStore notification to the other OSCs in the pool. This results in snapshots inserted, but with no EC around to clean up, the snapshots are never removed.
The text was updated successfully, but these errors were encountered: