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 <[email protected]<mailto:[email protected]>>
Senior Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps
_______________________________________________
hibernate-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/hibernate-dev
