Page History

...

The semantic of the cache() / invalidateCache() API has gone through extended discussions. The rejected alternative semantics are documented below:

Rejected API Option 1

API

// Do not return anything
void cache();
// Alternatively, return the original table for chaining purpose.
Table cache();
 
// Physically uncache the table to release resource
void uncache();
 
// To explicitly ignore cache, not part of this proposal but in the future
Table hint(“ingoreCache”)

...

• Side effect: a table may be cached / uncached in a method invocation, while the caller does not know about this.

  Code Block
  language java title Side Effect Option 1
  { Table t = … // cache the table t.cache(); ... // The cache may be released in foo() foo(t); ... // cache is no longer available t.bar() } void foo(Table t) { // cache the table t.cache(); …. // Physically drop the table t.uncache(); }

  
  

Rejected API Option 2

API

// Return CachedTable
CachedTable cache();
 
public interface CachedTable extends Table {
  // Physically uncache the table to release resource
  void uncache();
}

...

• Optimizer has no chance to kick in.

• Users have to distinguish between original table / cached table.

• Adding auto cache becomes a backward incompatible change.

Rejected API Option 3

API

// Return a CacheHandle
CacheHandle cache();
 
public interface CacheHandle {
  // Physically release cache resource
  void release();
}

...