I'm learning Clojure to see if it's something I can leverage at my current job, and more importantly, how I can convince my bosses that Clojure has a 'killer feature' over java that makes it worth the investment1.The feature that I'm guessing most clojure evangelists would tout is state management and concurrency.The example that I see often in blogs and books is an account balance thats being updated by multiple threads.  Clojures state management can always cleanly ensure that the balance will be accurate regardless of the number of threads reading and writing that value.In practice, though, an application would never allow an account balance to live only in memory, it would have to be persisted outside of the JVM (probably in a database) for two hopefully obvious reasons:If the app goes down the database will need to accurately reflectthe latest state for recovery.  For this reason the database cannot be asynchronously updated, and all reads would have to block until the database update is complete.If other applications are reading ormanipulating the account balance (maybe because weve scaled our appout to several servers), that balance would need to be kept in syncbetween all instances.Can Clojures state management handle situations like this elegantly?  For instance, given scenario 2 above, all reads of the account balance would first need to check the database to get the value, and if the database is locked, it would have to block until the correct value is available, no?Its great that Clojure handles my in-memory concurrency very elegantly but if that elegance cant be extended to external state then do I really gain anything?1(note that things like expressiveness, elegance, etc. are rarely considered killer features by mgmt.)
Clojure state and persistence
design;clojure;persistence;state