okaywit / guava-libraries

Automatically exported from code.google.com/p/guava-libraries
Apache License 2.0
0 stars 0 forks source link

Add option to overflow cache to disk #1481

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I wished, Guava caches would provide a possibility to overflow to disk. I wrote 
my own solution which I summarized here:

http://www.mydailyjava.blogspot.no/2013/07/extending-guava-caches-to-overflow-to
.html

I think, this would be a great addition to Guava caches because some expensive 
objects can be serialized and deserialized easily while only be constructed 
under quite some effort, for example if they require computation as in my use 
case. 

A native solution could fix the problem with the RemovalListener not being 
synchronized on a cache entry's key which I mentioned in my blog entry.

Of course, I know that Ehcache offers this feature, but I often prefer Guava 
caches since they imply much less weight.

I think this would really make a great feature!

Original issue reported on code.google.com by rafael....@gmail.com on 18 Jul 2013 at 3:16

GoogleCodeExporter commented 9 years ago

Original comment by cgdecker@google.com on 18 Jul 2013 at 3:25

GoogleCodeExporter commented 9 years ago
imho, if you have to specify your marshalling logic anyway, then in many(most?) 
cases you would really want a memory-managed cache. Which would be ridiculously 
more GC-friendly, and let you actually configure the exact amount of memory 
your cache can use (which many people want), but would be a completely 
different implementation from what we have.

Original comment by kevinb@google.com on 18 Jul 2013 at 4:47

GoogleCodeExporter commented 9 years ago
Well, I agree about the marshalling logic but only as long as we are speaking 
about abstract persisting caches and not about caches that fall back to the 
local file system which I believe is the most typical use case. (At least 
Ehcache is offering this feature.)

Also, such a file fallback cache would use the exact same amount of memory as 
any other Guava cache since the extra persisted entries are only stored on disk 
and not in memory. Of course, the interface contract would change slightly, 
since entries would not be removed from a cache but they would overflow to disk 
and get retrieved whenever they are required as long as someone implemented a 
logic that allows to specify other behavior. (Again, Ehcache allows such logic 
but brings other disadvantages.)

I wrote an implementation in form of a wrapper to a "normal" Guava caches: 
https://github.com/raphw/guava-cache-overflow-extension

At least for my use case where (de-)serialization is way cheaper than 
construction, this works really well.

However, I understand that this goes away from what Guava caches originally 
intend. If someone has a similar requirement than me, feel free to use my code.

Original comment by rafael....@gmail.com on 22 Jul 2013 at 12:15

GoogleCodeExporter commented 9 years ago
I have a different use case that would benefit from making the RemovalListener 
synchronized on a cache entry's key.  See 
https://code.google.com/p/guava-libraries/issues/detail?id=1531.

Original comment by bent...@gmail.com on 12 Sep 2013 at 6:24

GoogleCodeExporter commented 9 years ago
This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<issue id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:12

GoogleCodeExporter commented 9 years ago

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:17

GoogleCodeExporter commented 9 years ago

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:08