FWD » Core Development » Database

I see Session.invalidateRecords as a constant bottle-neck in my profiling. Most of the times, TemporaryBuffer triggers this invalidation due to multiplex scope close or table clear (due to table parameter output copy, empty-temp-table or copy-temp-table).

The implementation is traversing the whole cache in the search of the records which should be removed. As the cache has 1024 records, this is inefficient and surely disallows us to increase the cache size without firing back. There are two issues here:

• The records are not filtered by the table. There is no quick way to find the records which should be pruned.
• The records store the multiplex in the value, not the key. Therefore, we should extract it from the value at each step as we don't have access to it in the key.

• pufIfAbsent on associate
• keys to deregister from versioning
• remove on evict
• get on cache look-up
• cacheExpired on entry expiry

All of these are intensively used, so we shouldn't spoil the performance here. We need something like bulk identify (not remove - allow us to independently do the remove of each cache entry).

My initial idea here is to extent the cache with an additional WeakHashMap, much like the ffCache does with ReverseLookup. However, I don't have a clear idea of how the RecordIdentifier can help us here as a WeakHashMap key, when we are in need of a segregated table / multiplex / id key.

• The putIfAbsent will work by creating the required table entry / multiplex entry / recid entry.
• The keys and get won't affect this mapping
• The remove will need to do the proper remove here and clear-up. If the table / multiplex / recid map is empty, remove the entry from the parent map.
• The cache expiry will also trigger a remove in the mapping.

The prune is basically an in-depth get on this second map. The down-fall here is the need of creating one HashMap per table and one HashSet per multiplex of a table. I also expect a lot of trashing by removing / adding maps here.

Please let me know if you have other suggestions that can be applied here!

I have reviewed revision 14571 of 7026d. I totally agree with the code. Good job!

1. dropping the extra .getName() calls and the strings do not need to be eventually interned (although I think they already are in this case);
2. the .class is an identifier so the much faster IdentityHashMap could be used (the calls to .equals() are replaced by ==).

Eric,
I remember we already have discussed choosing between String to Class<?>, but I do not remember why we stick to the former. Using the class name allows uncoupling the content of the cache from the DMO class which would allow the class to be unloaded (for dynamic temp-tables). However, we must evict the records first from the cache before DMO class unloading or else they will age forever, leaking memory.

Ovidiu, you are right: I don't want to use Class instead of String with RecordIdentifier. We need to eliminate strong references to DMO classes (I mean this in the general sense, including interfaces), so transient DMO classes can be unloaded when they are no longer in use. We already have strong references to these in numerous places (e.g., in the GCD proxy implementation, where DMO interfaces are stored in the cache keys). I don't want to add more; it's already a mess to untangle what we have.