Mike Cheung wrote:Hi, sorry general question about caching here. My understanding is that they are all just name-value pairs. I know EHCache is a popular cache of choice, and so is Oracle Coherence, amongst others such as JBoss's Infinispan, Java Caching System, or Cache2K, etc.
What I don't understand is why would I use these alternatives than what's available from out of the JDK box such as the following.
Mike Cheung wrote:
My use case is to have a server-client system, with the following characteristics:
1) Server holds multiple tables of arbitrary number of rows and columns in memory. The tables can store data such as interger, double, and string in the the table cells.
2) Multiple clients can connect to the server and browse through the tables at any time after the connection, and the server needs to serve the requested tables to the clients.
Henry Wong wrote:
If you want to code the clients to request the data, and code the server to service the data, then a concurrent hashmap should be fine. However, if you just want to share the cache, and let the caching library deal with the requesting and servicing, then it may be easier to use a cache.
Keep in mind though, with many of these caching systems, the changes made by any client will also be reflected back on the server (and on other clients), so it may *not* be what you want.
Henry
Mike Cheung wrote:What I don't understand is why would I use these alternatives than what's available from out of the JDK box such as the following...
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:Well, off the top of my head, the example you gave doesn't appear to have any way of limiting the cache size, which is normally advisable in high-volume situations; but just FYI, a very simple size-limited LRU cache can be built on top of a LinkedHashMap.
Sounds like you're probably past the "roll your own" stage though...![]()
Winston
1) Multiple tables to be held in memory.
2) Each table's structure (ie name and number of columns, number of rows, content of the cells) are to be determined at run time.
3) Ability to insert / remove columns anywhere after table is created.
4) Ability to insert / remove rows anywhere after table is created.
5) Ability to populate / update cells anywhere after table is created.
6) Ability to inject call back methods to be well ... call backed, upon changes to the table.
This I think I can do easily by creating an array of funciton pointers, and iterate them through whenever the methods that are used to update the table are called upon.
7) Ability to allow incoming request for the current view of the table, to get the table without being corrupted by incoming requests to make changes to the table (ie insert / remove columns / rows, populate / update cells).
8) Ability to do simple joins across different tables.
Mike Cheung wrote:Um.. I need to represent tables in memory so there can't be any LRU do discard data.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
Mike Cheung wrote:Um.. I need to represent tables in memory so there can't be any LRU do discard data.
OK, but the rest of your requirements sound like a database, not a cache, so I'd look at a database solution - perhaps a NoSQL one, because it doesn't sound like you need all the ACID properties.
I'm afraid I can't really advise on which are the best, because I've been an RDBMS guy all my life; but this definitely sounds beyond the sort of thing I would try to roll by myself.
Winston
What a show! What atmosphere! What fun! What a tiny ad!
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|