core/src/main/java/org/sakaiproject/nakamura/lite/CachingManagerImpl.java
protected void putCached(String keySpace, String columnFamily, String key, Map<String, Object> encodedProperties,
            boolean probablyNew) throws StorageClientException {
        String cacheKey = null;
        if (sharedCache != null) {
            cacheKey = getCacheKey(keySpace, columnFamily, key);
        }
        if (sharedCache != null && !probablyNew) {
            CacheHolder ch = getFromCacheInternal(cacheKey);
            if (ch != null && ch.isLocked(this.managerId)) {
                LOGGER.debug("Is Locked {} ", ch);
                return; // catch the case where another method creates while
                // something is in the cache.
                // this is a big assumption since if the item is not in the
                // cache it will get updated
                // there is no difference in sparsemap between create and
                // update, they are all insert operations
                // what we are really saying here is that inorder to update the
                // item you have to have just got it
                // and if you failed to get it, your update must have been a
                // create operation. As long as the dwell time
                // in the cache is longer than the lifetime of an active session
                // then this will be true.
                // if the lifetime of an active session is longer (like with a
                // long running background operation)
                // then you should expect to see race conditions at this point
                // since the marker in the cache will have
                // gone, and the marker in the database has gone, so the put
                // operation, must be a create operation.
                // To change this behavior we would need to differentiate more
                // strongly between new and update and change
                // probablyNew into certainlyNew, but that would probably break
                // the BASIC assumption of the whole system.
                // Update 2011-12-06 related to issue 136
                // I am not certain this code is correct. What happens if the
                // session wants to remove and then add items.
                // the session will never get past this point, since sitting in
                // the cache is a null CacheHolder preventing the session
                // removing then adding.
                // also, how long should the null cache holder be placed in
                // there for ?
                // I think the solution is to bind the null Cache holder to the
                // instance of the caching manager that created it,
                // let the null Cache holder last for 10s, and during that time
                // only the CachingManagerImpl that created it can remove it.
            }
        }
        LOGGER.debug("Saving {} {} {} {} ", new Object[] { keySpace, columnFamily, key, encodedProperties });
        client.insert(keySpace, columnFamily, key, encodedProperties, probablyNew);
        if (sharedCache != null) {
            // if we just added a value in, remove the key so that any stale
            // state (including a previously deleted object is removed)
            sharedCache.remove(cacheKey);
        }
    }
protected void putCached(String keySpace, String columnFamily, String key, Map<String, Object> encodedProperties,
            boolean probablyNew) throws StorageClientException {
        String cacheKey = null;
        if (sharedCache != null) {
            cacheKey = getCacheKey(keySpace, columnFamily, key);
        }
        if (sharedCache != null && !probablyNew) {
            CacheHolder ch = getFromCacheInternal(cacheKey);
            if (ch != null && ch.isLocked(this.managerId)) {
                LOGGER.debug("Is Locked {} ", ch);
                return; // catch the case where another method creates while
                // something is in the cache.
                // this is a big assumption since if the item is not in the
                // cache it will get updated
                // there is no difference in sparsemap between create and
                // update, they are all insert operations
                // what we are really saying here is that inorder to update the
                // item you have to have just got it
                // and if you failed to get it, your update must have been a
                // create operation. As long as the dwell time
                // in the cache is longer than the lifetime of an active session
                // then this will be true.
                // if the lifetime of an active session is longer (like with a
                // long running background operation)
                // then you should expect to see race conditions at this point
                // since the marker in the cache will have
                // gone, and the marker in the database has gone, so the put
                // operation, must be a create operation.
                // To change this behavior we would need to differentiate more
                // strongly between new and update and change
                // probablyNew into certainlyNew, but that would probably break
                // the BASIC assumption of the whole system.
                // Update 2011-12-06 related to issue 136
                // I am not certain this code is correct. What happens if the
                // session wants to remove and then add items.
                // the session will never get past this point, since sitting in
                // the cache is a null CacheHolder preventing the session
                // removing then adding.
                // also, how long should the null cache holder be placed in
                // there for ?
                // I think the solution is to bind the null Cache holder to the
                // instance of the caching manager that created it,
                // let the null Cache holder last for 10s, and during that time
                // only the CachingManagerImpl that created it can remove it.
            }
        }
        LOGGER.debug("Saving {} {} {} {} ", new Object[] { keySpace, columnFamily, key, encodedProperties });
        client.insert(keySpace, columnFamily, key, encodedProperties, probablyNew);
        if (sharedCache != null) {
            // if we just added a value in, remove the key so that any stale
            // state (including a previously deleted object is removed)
            sharedCache.remove(cacheKey);
        }
    }
protected void putCached ( String keySpace , String columnFamily , String key , Map < String , Object > encodedProperties , boolean probablyNew ) throws StorageClientException { String cacheKey = null ; if ( sharedCache != null ) { cacheKey = getCacheKey ( keySpace , columnFamily , key ) ; } if ( sharedCache != null && ! probablyNew ) { CacheHolder ch = getFromCacheInternal ( cacheKey ) ; if ( ch != null && ch . isLocked ( this . managerId ) ) { LOGGER . debug ( "Is Locked {} " , ch ) ; return ; // catch the case where another method creates while // something is in the cache. // this is a big assumption since if the item is not in the // cache it will get updated // there is no difference in sparsemap between create and // update, they are all insert operations // what we are really saying here is that inorder to update the // item you have to have just got it // and if you failed to get it, your update must have been a // create operation. As long as the dwell time // in the cache is longer than the lifetime of an active session // then this will be true. // if the lifetime of an active session is longer (like with a // long running background operation) // then you should expect to see race conditions at this point // since the marker in the cache will have // gone, and the marker in the database has gone, so the put // operation, must be a create operation. // To change this behavior we would need to differentiate more // strongly between new and update and change // probablyNew into certainlyNew, but that would probably break // the BASIC assumption of the whole system. // Update 2011-12-06 related to issue 136 // I am not certain this code is correct. What happens if the // session wants to remove and then add items. // the session will never get past this point, since sitting in // the cache is a null CacheHolder preventing the session // removing then adding. // also, how long should the null cache holder be placed in // there for ? // I think the solution is to bind the null Cache holder to the // instance of the caching manager that created it, // let the null Cache holder last for 10s, and during that time // only the CachingManagerImpl that created it can remove it. } } LOGGER . debug ( "Saving {} {} {} {} " , new Object [ ] { keySpace , columnFamily , key , encodedProperties } ) ; client . insert ( keySpace , columnFamily , key , encodedProperties , probablyNew ) ; if ( sharedCache != null ) { // if we just added a value in, remove the key so that any stale // state (including a previously deleted object is removed) sharedCache . remove ( cacheKey ) ; } }
Put an object in the cache

@param keySpace
@param columnFamily
@param key
@param encodedProperties
the object to be stored
@param probablyNew
whether or not this object is new.
@throws StorageClientException
Put an object in the cache