I've been reading up on Erlang a little more. I've been curious how a completely functional language deals with things that need to be persisted. Basically, anything persisted is a kind of mutable state and I was curious how in the world Erlang copes with race conditions.
It turns out you can mark the DB code to run in a transactional context. In Erlang this does more than just rollback everything if something fails - it actually puts a pessimistic lock on the rows or table and will even run away like a smart
chicken when it sees potential for deadlock.
I would suppose that in Scala you would have to handle all this yourself. Another possibility would be to let Hibernate handle its optimistic locking mechanism... but then your domain objects wouldn't work as well if your Scala code started passing them around in multiple processes. I mean, a lot of their value is in being able to alter their state.
So this leads me to think that Scala in a basic CRUD application isn't such a great idea... or at least utilizing a functional style of programming in Scala for a basic CRUD app isn't optimal. You could still use Scala imperatively.
I've been thinking through a lot of past projects, wondering where functional style programming could have saved some headache.
There've been times where an asynchronous call was needed and for some reason most people immediately jump to the conclusion that MDBs are the best solution for anything asynchronous rather than bother to multithread.
There have also been plenty of times where multithreading some utility processes would have sped up the response (incredibly more so now with multicore processors) but the riskiness of creating a potential maintenance nightmare usually outweighed the benefits of pursuing it.
If I were to introduce a functional style of programming into an enterprise application, where would be the ideal place for it?