But, sometimes (often?) the key is not a simple attribute key but a compound key (I recommend to use ERXMultiKey for that purpose). In that case, there is no magic.
First, you have to understand that ERXEnterpriseObjectCache has no way to fetch the missing EOs. So you have to handle it manually.
Secondly you have to use the constructor with the parameter shouldFetchInitialValues set to true which is incorrectly named (more later). As a result, the EOs are entirely fetched when the cache is create and if there are thousands of records or more, no luck!
Why shouldFetchInitialValues is incorrectly named IMO? Because it implies 2 behaviors not reflected by the parameter name: one is to warm up the cache and the second implicit behavior is to tell ERXEnterpriseObjectCache to not fetch objects. When you look at the API, it's not obvious at all.
Of course, the temptation is high to enhance ERXEnterpriseObjectCache but if you don't need an EOs cacheyour need is to cache globalID rather than EOs, you can use another an interesting library: Guava.
So think twice how you will use your EOs. But often, you use a cache to retrieve quickly objects you add to relationships. In this particular case there are some good news.
First check in your code if you use addObjectToBothSidesOfRelationshipWithKey() because EOF will resolve the fault. Always. If you can, avoid to call this method but call takeStoredValueForKey(). Even if you call takeStoredValueForKey(), if you look at the code in the ERXGenericRecord class, you'll see it will update the inverse relationship if you set the property er.extensions.ERXEnterpriseObject.updateInverseRelationships to true. Instead, set this property to false.
To sum up: if your cache contains EOs you use mainly to set relationship with other objects, and if your application tolerates to not update the inverse relationship, you can advantageously use Guava. And don't forget you can cache other objects which are not Enterprise Objects with Guava.