LRU queue or heap data structure implementation?

Jay Nelson jay@REDACTED
Thu Nov 24 06:15:00 CET 2005

Richard Cameron wrote:

> ... so this sounds like a purely in-memory database where each "row"  
> of data is actually a process, with a mind of its own. I'm sure if  
> you took that to its logical conclusions you could build a  
> particularly wacky variant of a relational database (where foreign  
> keys between "rows" are paths you can send messages over). 

Hmm, a little further than I was thinking.  I forgot to put the 
assumptions I thought I read from your post and a browse of your website:

1) Most accesses are read accesses only
2) You want to retrieve data from database and wrap it in HTML for delivery
3) You would like to lighten the load on your server
4) Updates could be more costly to the user

1-3 can be gotten by one retrieval from the DB starting a process which 
prepares the HTML.  Subsequent request just return the same HTML (or a 
slight variant) directly from the running process without visiting the 

4 requires killing the HTML process, updating the database as now and 
respawning the process as a new request.

Timeouts just free memory occupied by previously spawned and wrapped 
HTML tidbits from the database.  If no one has requested them recently, 
you can safely throw them away.  The timeout time should be relative to 
the construction time, CPU effort and frequency of user requests, with 
an eye towards the amount of memory consumed.  Frequently visited pages 
that don't change often (e.g., FAQ page) can be "pinned" to the cache so 
they aren't killed unless the data is stale.


More information about the erlang-questions mailing list