Skip to content

Commit

Permalink
Add note about getSync to the readme, fix code sample
Browse files Browse the repository at this point in the history
  • Loading branch information
Chris Birchall committed May 7, 2015
1 parent dd16cfa commit 7bc5888
Showing 1 changed file with 16 additions and 4 deletions.
20 changes: 16 additions & 4 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -45,19 +45,19 @@ Assuming you have a `ScalaCache` in implicit scope:
import scalacache._

// Add an item to the cache
put("myKey")("myValue")
put("myKey")("myValue") // returns a Future[Unit]

// Add an item to the cache with a Time To Live
put("otherKey")("otherValue", ttl = 10.seconds)

// Retrieve the added item
get("myKey") // Some(myValue)
get("myKey") // returns a Future of an Option

// Remove it from the cache
remove("myKey")
remove("myKey") // returns a Future[Unit]

// Wrap any block with caching
val result = caching("myKey") {
val result: String = caching("myKey") {
// do stuff...
"result of block"
}
Expand All @@ -72,6 +72,18 @@ val result = cachingWithTTL("myKey")(10.seconds) {
put("foo", 123, "bar")(value) // Will be cached with key "foo:123:bar"
```

### Synchronous cache reads

If you don't want to bother with Futures, you can do a blocking read from the cache using the `getSync` method. This just wraps the `get` method, blocking indefinitely.

```scala
import scalacache._

val myValue: Option[String] = getSync("myKey")
```

If you're using an in-memory cache (e.g. Guava) then this is fine. But if you're communicating with a cache over a network (e.g. Redis, Memcached) then `getSync` is not recommended. If the network goes down, your app could hang forever!

### Memoization of method results

```scala
Expand Down

0 comments on commit 7bc5888

Please sign in to comment.