Akka Agents do that exactly, you can read anytime while writes happen serially, of course Agents cannot benefit AFAIK from Akka Sharding functionality for example, hence making stash just like CurioDB does a better fit (if you need to redistribute these values)
Regards, Guido. On Thursday, March 17, 2016 at 11:27:51 PM UTC, Stephen McDonald wrote: > > > > On Friday, 18 March 2016 08:59:14 UTC+11, Rafał Krzewski wrote: >> >> Are you sure you are approaching the problem from the best angle? Akka >> gives you a guarantee that the execution of actor code is single threaded, >> so each time a message is processed, the code has an "exclusive lock" on >> the actor's internal state (quotation marks because there is actually no >> lock involved, just smart thread scheduling). >> >> Does your writer need to exchange several messages with the target actor, >> and the messages from readers should not be processed over the duration of >> that conversation? In such case, you should be able to implement it with >> little effort using become [1] and Stash [2]. For extra style points, >> you can use FSM [3] :) Just watch out for unbounded mailboxes when using >> Stash! Stashing large number of messages may exhaust heap space. >> > > Stash is perfect for this use case. We use it to implement write > transactions in CurioDB (https://github.com/stephenmcd/curiodb) > > - Each command an actor receives is read or write, and has its own > transaction ID > - When a write command is received and there's no current transaction, we > store the transaction ID as the current transaction > - When a write command is received and there is a current transaction ID, > we stash the command > - Once the transaction is finished, remove the transaction ID, and unstash > all previously stashed commands to be replayed > - Read commands can always read, no stash-base-lock needed > > > > >> >> Cheers, >> Rafał >> >> [1] http://doc.akka.io/docs/akka/2.4.2/scala/actors.html#Become_Unbecome >> [2] http://doc.akka.io/docs/akka/2.4.2/scala/actors.html#Stash >> [3] http://doc.akka.io/docs/akka/2.4.2/scala/fsm.html >> >> W dniu czwartek, 17 marca 2016 16:52:47 UTC+1 użytkownik neel choudhury >> napisał: >>> >>> I want to implement the famous reader writer model using actor model. We >>> can have multiple reader reading but only one writer can write. Also when a >>> writer writes no reader can read and vice versa. >>> >>> To solve this problem i thought of using a superviser actor which >>> maintains a set for reader actors and a queue for writer actors. Now a >>> writer can be dequeued and start writing when the set for readers are >>> empty. Also when the writer completes all reader actors from the set can >>> start reading. >>> >>> Can we have a better problem of solving this famous problem using actor >>> model? >>> >>> Also is this model better than the original reader writer problem soved >>> using read or write locks? >>> >> -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
