Some initial questions about Actors

Hi, all.  I'm a longtime programmer, but new to Scala.  I'm about to start building the next phase of my company's app using Actors, and I've got some questions.  I've read the obvious materials on the subject (the Short Tutorial on Actors, the Haller/Odersky paper, some of the book), and I think I understand the basic lay of the land, but I'm trying to get a better handle on best practices. 

(If it seems useful, I'd be happy to write stuff up as I understand it better, and put it into a wiki somewhere for the next guy to come along.  I'm a compulsive documenter, and decently good at it.)


So, first question: threading.  My understanding is that receive-based actors effectively "own" one thread out of the main Java thread pool, and react-based actors don't.  That seems to make the react-based model a slam-dunk choice for my purposes -- I'm going to have many Actors, most of them quiescent most of the time, so I can't afford for them to hold onto blocked threads.

However, I want to make sure I understand what threads *are* being used.  The Haller/Odersky paper makes it sound like react-based Actors camp on the thread of the caller, which I certainly don't want.  I'm not fretting too much, because the book makes it sound more like there's a thread pool that the reacts are being called from, but it's all a little vague.

So can someone give a quick two-paragraph explanation of how the threading works in a mainly react-based environment?  Is there, in fact, a thread pool somewhere that messages are being processed from?  And how do the Schedulers fit into all of this?  They have intriguing names, but no real documentation that I've found yet.


Second question: are there any established best practices for managing actor directories?  In my case, actions will generally originate at the client, which is going to be passing IDs around; when commands get to the server, I'll (at least sometimes) need some sort of routing tables to associate IDs with the Actors that need to receive the messages.  I can, obviously, homebrew something for this, but if there are already patterns for it, I might pick those up instead.


Third question: persistence.  My app is going to have more DB objects than really want to live in memory all at once -- for example, if a Person hasn't logged in for the past week, I don't want to be keeping the Actor representing him in memory.  So it's pretty clear that I'm going to need a framework that can receive a message for an Actor that is identified by ID, checks the directory, "rehydrates" the Actor from the DB if necessary and does the action.  (And can in some reasonable ways determine when an Actor has been untouched for a long time, and "dehydrate" it again -- a smart LRU system would be ideal.)  Again, I *can* build this myself, but if somebody's already got a general framework for it, it's probably worthwhile for me to use that.


Fourth question: clustering.  I'm a fair ways from needing to worry about this (I don't yet have a thousand users, much less the 10k or so that will force me to deal with scalaing), but want to get an idea of my options.  I've seen the work on Terracotta.  What else is out there?  I see scala.actors.remote, and that's fairly straightforward-looking, but it's also just the beginnings of a real clustering solution -- the directory and persistence issues become much more interesting and important in a clustered environment.  Are there yet projects building on scala.actors.remote to create an open clustering stack?


Thanks for any insight you can provide.  I'm quite excited by the whole thing -- I'm a lifelong languages geek (I've worked professionally in probably 25 different languages), and Scala is the most intriguing I've seen to date.  And the Actors architecture is very appealing and logical as a way to deal with the issues of complex threaded applications...