[hibernate-dev] Question regarding method ReadWriteEhcacheNaturalIdRegionAccessStrategy#afterInsert

[Demetz, Guenther]

Hi Alex,

thank you very much for the response

>> Iirc we expect no entry, as the softlock should have been removed, right?

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.

>> Sorry for lagging

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:

>> if ( item == null || item.isWriteable( region.nextTimestamp(), null, null ) ) {
>>    region.put( key, new Item( value, null, region.nextTimestamp() ) );

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 at gmail.com<mailto:alex.snaps at gmail.com>>
Senior Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps