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