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?
I've been waiting for someone to answer this post for a while because I am
a.) Interested in what others opinions are, and b.) wholly unqualified to answer the question as it was posed myself
Therefore hopefully without sounding too ignorant, I'll give my 2 cents.
MP: Basically, anything persisted is a kind of mutable state and I was curious how in the world Erlang copes with race conditions.
Dealing with race conditions is definitely out of the scope of my knowledge, but as to dealing with persistence in a functional language, from what I've seen from Haskell DBC libraries (which are *purely* functional) deal with database CRUD interactions the same way all IO is modeled in the language, with monads. In Haskell it's the IO Monad that is usually used, but I suppose a user defined monad would work.
Oo - new toy! I'll mess with that over the weekend some. Thanks, Garrett!
A web framework might actually be a great way for Scala to get into the enterprise. I'll bet it has an Actor as a Front Controller. Shoot, even individual Servlet/Action/Command objects could be Actors.
I suppose my questions about race conditions probably aren't that big a deal. We have to deal with them in web applications (which are multithreaded) all the time in Java.
A Mnesia transaction is a mechanism by which a series of database operations can be executed as one functional block. The functional block which is run as a transaction is called a Functional Object (Fun), and this code can read, write, or delete Mnesia records. The Fun is evaluated as a transaction which either commits, or aborts. If a transaction succeeds in executing Fun it will replicate the action on all nodes involved, or abort if an error occurs.
Originally posted by Pho Tek: Have you also looked at Erlang mnesia.
Yeah, my comment of: "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."
actually was talking about Erlang's Mnesia transactions.