[erlang-questions] "actor database" - architectural strategy question

[Miles Fidelman]

Ahh... thanks!  Now I know what to look for as a start perusing the 
riak_core architectural documents.

Re. a couple of your other points:

Michael Radford wrote:
> I was addressing exactly your second point: backing up and restoring actors.
>
> Since you brought up that point, it didn't sound like an "actor" in
> your model is 1-1 with an Erlang process for all time. So OK, you can
> checkpoint them and restart them. But what if you want the "actor" to
> continue to "respond to messages" when any single machine crashes?
> Maybe multiple Erlang processes on multiple machines can coordinate to
> provide a highly available representation of your per-document actor.

In some sense, I keep coming back to the model of paper documents - but 
just a little bit "smarter."
- I have a copy of the same document at the office, at home, in my 
briefcase, someone else has a copy
- updates can be distributed via copy machine and mail
- with paper, if one of them gets lost or stolen, there are other 
copies, but you lose marginal notes
- add a little "intelligence" and now copies can be synced (a la what we 
do with our smart phones and laptops) - with the sync logic embedded in 
the document rather than the environment (which is makes the actor-like 
rather than simply files or object-like)
- which does address one approach to backup - things are mirrored, if a 
node crashes, there are other copies around, it's easy to restore state 
(the only time things get lost is if one is running disconnected and 
things crash) -- though it becomes pretty inefficient if the power 
fails, or you want to reboot the machine, or what have you
>
> For the same reason, it sounds like you need reliable messaging, so
> that a locally-triggered change isn't lost if a machine crashes. So
> you may need to persist the update messages in multiple places.

I'm thinking that this is embedded in publish subscribe channels, with 
logs/archives.  I keep coming back to a USENET/NNTP model for both 
messaging and replication.
>
> Finally, you also mentioned "copies of documents" with "local changes"
> triggering changes in other copies of the documents. What if the
> locally-triggered changes conflict?

For this, I'm thinking that each document has an embedded change control 
system.  Akin to having one's own copy of a git repository. (The Fossil 
distributed version control system is a really nice model for this.)
>
> For example, a budget with a total, where any user can add or remove
> line items. To compute the current total, you need rules for resolving
> conflicting additions and removals of the same line item. Since you
> mentioned that these changes are "local" and you're sending messages
> among the document actors, it sounded like you had something like this
> in mind.

Exactly.  Which is one of the things that leads me to the actor model - 
embed the rules directly in each copy of the document, rather than in 
external logic.
>
> If any of these things are a concern for your application, I thought
> you might find the ideas behind riak-core helpful at least.

Thanks!  I'm going off to look now!


-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra