Re: [hibernate-dev] Question regarding method ReadWriteEhcacheNaturalIdRegionAccessStrategy#afterInsert

Hi Alex, thank you very much for the response The softlock is actually not removed when using read-write strategy. I did implement the delete handling of natural-id analog to the way it is for entities, where the procedure is following: 1. Lock the cache entry on predelete: lock = persister.getCacheAccessStrategy().lockItem( ck, ... ); 2. Remove the entry on post-delete persister.getCacheAccessStrategy().remove( ck ); 3. Unlock the lock after transaction completion getPersister().getCacheAccessStrategy().unlockItem( ck, lock ); Now when using read-write strategy, on step 3 the softlock get not removed, it get only modified by resetting multiplicity to zero. /** * Unlocks this Lock, and timestamps the unlock event. */ public void unlock(long timestamp) { if ( --multiplicity == 0 ) { unlockTimestamp = timestamp; } } This is the reason why on after insert event there may already exist a value mapped to the given key. For entities I believe this is not a problem, since primary keys are usually not being recycled. But on natural-id's the recurrence of determinate values is quite realistic. no problem, this has absolutely no urgency (moreover I will now be away for a week). And maybe in meantime someone else of hibernate-developers could find an explanation. best regards Guenther On Wednesday, June 13, 2012, Demetz, Guenther wrote: Hi Alex, I have a question in regard to class ReadWriteEhcacheNaturalIdRegionAccessStrategy where you are listed as co-author. Do you maybe know, why inserts do only succeed if there is no existing value mapped to the actual key? Code-snippet of ReadWriteEhcacheNaturalIdRegionAccessStrategy#afterInsert << if ( item == null ) { << region.put( key, new Item( value, null, region.nextTimestamp() ) ); Namely I did expect, that in case of item being an "unlocked" Lock, the insert should succeed nonetheless. Something like following: I ask because after trying to resolve a Todo in StatefulPersistenceContext (you find it by searching for "should be using access strategy, not plain evict.. "), some test in CachedMutableNaturalIdStrictReadWriteTest fails exactly because such "re-caching" attempts do not succeed anymore. best regards Günther -- Alex Snaps <alex.snaps@gmail.com<mailto:alex.snaps@gmail.com>> Senior Software Engineer - Terracotta http://twitter.com/alexsnaps http://www.linkedin.com/in/alexsnaps