depends on the orm right?
there are plenty ways to do it. I've got idea, when db connections are distributed using token pattern - there is an actor which holds pool of tokens/db connections, and passes them on demand to other actors inside the same actor system, actors which needs a db access, ask provider wth token request and release the token after their job is done
however it's only an idea, I didn't test it yet
@kekekeks what @annymsMthd said is completely true. the thing to realize is: Akka has 5 years of battle tested implementation working for lots of people in most varied environments. It's more about understanding how you can do it than anything else. the model itself doesn't restrict much, but you need to change your application architecture to embrace it.
dispatchers control how threads are used. you can run 10 queries using a single thread if you're using async
(that's exactly why I'm trying to come up with some reasons why someone should touch dispatchers - we need some good examples on why one would care about that)
I've already proposes an experiment for custom dispatcher built on top of Hopac to see, if there is a possible performance gain
Hopac. yeah that should be interesting
you don't notice after some time. but for people learning, it's a lot of words that don't mean a lot
yep, exactly
I agree they are useful. but it's not what akka.net needs to attract new people
I tried to explain akka.net to some friends, they have a lot of questions that I only know because I'm here everyday and reading the issues and going through the source. it's not a good path for everyone
they deal with very different problems than me :P
you guys win hands down
I have been playing around trying to find a good way to do stateful actors in a hierarchy. After talking with @Aaronontheweb that HashPooling was not a good idea so I came up with a sample project. Besides adding become logic I was wondering if anyone had any thoughts or criticism on how to model this using Akka.