• New Feature
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • lorban
  • Reporter: kbhasin
  • August 17, 2010
  • 0
  • Watchers: 1
  • November 01, 2010
  • August 23, 2010

Description

Kunal

BlockingCache has this type of behaviour right now. So yes, let’s add the timeout as you suggest.

Suggested Design

Call the config parameter timeoutMillis. It will be an optional parameter. If absent or set to 0 the load will not timeout. If it is set it will timeout after that time and throw a LoadTimeoutException, which will be a subclass of CacheException.

On 17/08/2010, at 9:08 AM, Kunal Bhasin wrote:

Hey Greg

The following implementation of getWithLoader will wait on condition for the future to complete forever i.e. if a database call takes a very long time. Does it make sense to provide a timeout here (fufture.get(timeout) on line 1415 )?

1379 /** 1380 * This method will return, from the cache, the Element associated with the argument “key”. 1381 * <p/> 1382 * If the Element is not in the cache, the associated cache loader will be called. That is either the CacheLoader passed in, or if null, 1383 * the one associated with the cache. If both are null, no load is performed and null is returned. 1384 * <p/> 1385 * If the loader decides to assign a null value to the Element, an Element with a null value is created and stored in the cache. 1386 * <p/> 1387 * Because this method may take a long time to complete, it is not synchronized. The underlying cache operations 1388 * are synchronized. 1389 * 1390 * @param key key whose associated value is to be returned. 1391 * @param loader the override loader to use. If null, the cache’s default loader will be used 1392 * @param loaderArgument an argument to pass to the CacheLoader. 1393 * @return an element if it existed or could be loaded, otherwise null 1394 * @throws CacheException 1395 */ 1396 public Element getWithLoader(Object key, CacheLoader loader, Object loaderArgument) throws CacheException { 1397 1398 Element element = get(key); 1399 if (element != null) { 1400 return element; 1401 } 1402 1403 if (registeredCacheLoaders.size() == 0 && loader == null) { 1404 return null; 1405 } 1406 1407 try { 1408 //check again in case the last thread loaded it 1409 element = getQuiet(key); 1410 if (element != null) { 1411 return element; 1412 } 1413 Future future = asynchronousLoad(key, loader, loaderArgument); 1414 //wait for result 1415 future.get(); 1416 } catch (Exception e) { 1417 throw new CacheException(“Exception on load for key “ + key, e); 1418 } 1419 return getQuiet(key); 1420 }

Comments

gluck 2010-08-18

Steve

Yes this is a good idea, and consistent with what we do in BlockingCache.

Ludovic Orban 2010-08-23

done.