Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search




I'm not sure this new mode should be the default. For one it seems highly experimental, and perhaps not something we want to introduce as the default close to a release. But more importantly it breaks the transactional cache. If you read any object once it an EntityManager, then re-read it again, it will no longer be in the transactional cache, and will need to be re-built, if you use an isolated cache, then it will need to be re-queried from the database. 08:53, 24 April 2008 (EDT)

Yes, setting it to the default is premature as users who use the PersistenceContext like a cache will loose that functionality. The transactional nature of the UOW will only be broken in one case though and that is a combination of not using the object in the application and having it garbage collect when that object is ony storing the version number in the cache. (Just thought of this now) all other cases will not impact the transaction. 09:00, 24 April 2008 (EDT)


Adding weak references all over the unit of work seems like it will add significant performance overhead. Also even in the HARD mode it seems that the checks for this will add significant performance overhead. This performance impact of this feature should be measure in detail. Also the uow currently uses an optimized identity map class that avoids all of the locking overhead of the session maps, switching to weak identity map will remove this optimization. 08:53, 24 April 2008 (EDT)

The HARD mode should have no performance impact over the current mode. It is only checked when creating the collections for the batchRead objects, the cloneMapping and the identity maps there are no operational checks for the ReferenceMode. The UOW will continue to use an optimized IdentityMap with this feature. The new WeakIdentityMaps are extended from the UOW maps. 09:00, 24 April 2008 (EDT)

Reference Queues

Using reference queues in weak identity maps is an intriguing idea. Avoiding the large performance bottleneck of the cleanup would be very desirable. I would like to see how this will work discussed more in this document. Also performance impact should be measure to see if there is a positive or negative improvement, if negative then this should not be implemented. 08:53, 24 April 2008 (EDT)

As the impact of the ReferenceQueue is limited to when the WEAK and FORCE_WEAK modes are used and we will not be using these as the defaults evaluating performance of this feature should not gate checkin of this feature. 09:00, 24 April 2008 (EDT)
I would be more interested in using the ReferenceQueue in the main WeakIdentityMap, it seems like it may be a major benefit, but would need to be tested. 15:29, 24 April 2008 (EDT)

Back to the top