I am new to Akka and actor framework - I am sure I am missing something obvious, please accept my apologies in advance.
I keep reading that one of the main points to choose Akka is the way it manages concurrency.
It is not clear to me why Akka is so special; I understand that there are many little actors which are very light and fast; however, how can this help me when two users save a form at the same time?
Wouldn't I still need some sort of concurrency lock (pessimistic/optimistic/etc..)?
One of the advantages of message-processing models like actors and agents is that the traditional concurrency problems (primarily synchronization of shared state) are no longer a problem. The actor can keep private state and update it freely without locks. The actor framework ensures that only one message is processed at a time. With serialized processing, code can be written in a lock-free way.
In your example of users saving a form, assuming the actor was keeping a List of some data from each form, the actor can update the list without locks, because the framework guarantees that only one form will be processed at a time. Traditionally, you would have to lock around the List accesses or use a concurrent list.
Concurrency strategy is a slightly different matter and is still your responsibility (with no strategy being the most common strategy). To change your example slightly, let's say that both users try to update the SAME form instance at the same time. With no concurrency strategy, one's changes will overwrite the other (probably last one wins). That's fine, but at best this results in unexpected behavior for the user whose changes got overwritten. If they view the form they just changed, it will have unexpected values (from the other user). At worst (when we're not just talking about form updates, but things like shipping orders) it could result in losses of various kinds (time, revenue, etc.).
Using a concurrency strategy helps to identify these cases and be able to resolve them based on business rules. For instance Optimistic Concurrency has the user send the version of the form it is updating. When the actor goes to process the change, it notices that the 2nd user thinks it's updating Version 5 when the form is actually at Version 6 because of the first user's update. Now at least we can notify the 2nd user that the form has already changed since they started editing it. Or whatever rules the business wants to enforce there.
In the case of updating a form, you probably don't care as much about concurrency (depends, I guess). But in other cases, it may be a very important thing to at least be able to check and handle violations. You may even want to ignore the concurrency violation, like if the users changed different sections (to continue the form analogy). Or if the change has a large impact on the business (a big order), you want to accept it and resolve minor conflicts later (e.g. yearly contact info update hasn't been completed).
I believe Akka has a number of other dimensions like how it handles failures, supervisors, etc. that are important considerations for devops.
I'm going to write about the Actor Model in general (not just Akka) in comparison with other concurrency models such as the classical lock-based concurrency and the neat transactional memory.
Easier concept to understand and use
Lock based concurrency is difficult; in particular is very difficult to get it right because there are many concepts to understand and use in order to be correct and efficient: locks, semaphores, threads, synchronization, mutual exclusion, memory barrier etc.
Actors, on the other hand are a more abstract concept; you have actors which send and receive messages. No need to grasp and use low-level concepts such as the memory barrier.
Less error prone
Not all languages easily enforce immutability;
Still pretty complex
Does not prevent deadlock or starvation
Not so efficient
Lock-based concurrency is the most efficient but it's hard to program and error-prone; software transactional memory is the most clear, easy to program and less-error prone but it's also the least efficient. Actors are somewhere in between these two models with all aspects: easy of programming, efficiency and error proneness.
Do read this blog: http://www.thinkpalm.com/blogs/introduction-akka-framework/ In here you can get an idea on " How Actor model solves the concurrency issue?"