title: Cleaning up state on code reload when running Ring and Compojure
body: <p>I'm writing a Compojure based application and can't get the hang of how to handle cleaning up state when the code is reloaded. Specifically, my app has an open handle to a LevelDB database, and this needs to be either reused or closed properly before it is opened again.</p>
  
  <p>I've looked around for different suggestions on how to deal with state in Compojure applications, and found two patterns. The first one, which can be seen in this <a href="https://stackoverflow.com/questions/17742204/using-leveldb-in-a-ring-compojure-webapp">SO question ("Using LevelDB in a Ring Compojure webapp")</a> suggests using a global var referencing an atom/ref/delay (I've seen a few different suggestions). This solution doesn't seem ideal to me, it's essentially global mutable state, and it looks like it is strongly discouraged (for example in <a href="http://vimeo.com/46163090" rel="nofollow noreferrer">this presentation</a>). It's also unclear if it works with code reloading (maybe with <code>defonce</code> instead of <code>def</code>?)</p>
  
  <p>The second pattern is to inject state using a piece of middleware, like in <a href="https://stackoverflow.com/questions/19776462/passing-state-as-parameter-to-a-ring-handler">this SO question ("Passing state as parameter to a ring handler")</a>. This pattern looks much better since it avoids the mutable state, but it doesn't work with code reloading. Here is my code that uses that pattern:</p>
  
  <pre><code>(defn create-initial-state []
    {:db (delay (storage/create "data.leveldb"))})
  
  (defn add-app-state [handler state]
    (fn [request]
      (handler (assoc request :app-state state))))
  
  (defroutes app-routes
    (GET "/signals" request
      (handle-signals (:app-state request))))
  
  (def app
    (-&gt; app-routes
        (add-app-state (create-initial-state))
        (handler/site)))
  </code></pre>
  
  <p>The implementation of <code>handle-signals</code> isn't important so I've left that out. <code>storage/create</code> opens a LevelDB database and returns a handle. The database is wrapped in a <code>delay</code> to avoid it being created when the code loads in my tests. The division between <code>create-initial-state</code> and <code>add-app-state</code> is just to make it easier to reuse <code>add-app-state</code> in the tests without marrying it to the code that opens the database.</p>
  
  <p>When this code is run with <code>lein ring server-headless</code> it works fine until I edit the code, then it blows up on the next request since <code>app</code> has been recreated, and <code>create-initial-state</code> has run again. There is no longer any reference to the old database handle, but since LevelDB keeps lock files around to make sure that there is only one process using the database, and my code never closes the handle, opening a new handle is an error.</p>
  
  <ul>
  <li>How do people generally handle things like database connections, open files and sockets when code is reloaded in a Ring app, without resorting to global mutable state? I've seen <a href="http://vimeo.com/46163090" rel="nofollow noreferrer">Stuart Sierra's "Clojure in the Large" presentation</a> and it gives some good suggestions, but they feel way to complex for a tiny app like mine.</li>
  <li>Is there a way to register to get a callback when the code is about to reload, so that I can close the open database handle?</li>
  </ul>