[morsch]

Updating databases (e.g. views) is a common thing we do using Akka actors. While a DB call is running, you store incoming updates in a local var, and once the DB update is done, you start the next DB update with the whole batch. So you never have more than one concurrent DB call, and there is no race condition. This all fits in quite well into the actor model.

[mrkeen]

Actor's claim to fame is no race conditions because no shared state. Haven't you just reintroduced shared state with that approach?

[morsch]

No. I've introduced state, but no shared state; the "next batch" var is local to the actor and not shared.

Critically, the only one who updates the variable is the actor itself in its thread; it could be a plain list, and not a concurrent queue as it might be in a different multiple producer/single consumer architecture.

PS -- I'll add that in Akka itself, the actor's mailbox, in which messages accumulate until the actor next gets allotted a thread, is exactly a kind of concurrent queue, at least in its default implementation.