Clojurians
#code-reviews
<
2016-01-22
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

tomc22:01:50

Looking for a quick review of a small gist: https://gist.github.com/tomconnors/d3c9f76c50c63fefbaab - in general, I'm just unsure whether this is the right approach for ensuring that only one instance of a stateful resource is created when multiple threads might be requesting that resource at any time.

jonahbenton23:01:14

hey @tomc with jdbc data sources in particular, these semantics are handled internally in pool libraries like c3po. something like https://devcenter.heroku.com/articles/database-connection-pooling-with-clojure is a reasonable approach

jonahbenton23:01:38

c3po has internal locking and concurrency handling and so forth

jonahbenton23:01:53

another angle- the posted code is in the vein of a semaphore pattern in clojure- managing a counted resource- while using agents for mutual exclusion. conceptually that's fine, though there are more idiomatic approaches. however, there is a concrete reason not to use agents in a cases where there may be timing expectations on the resource consumer (e.g. usually when people want to talk to the database, they want to do it NOW)- send-off will cause the function to run in another thread, the scheduling around which is not guaranteed. agents are mostly useful for decoupling work that is not timing sensitive. say you have a bunch of time-sensitive jobs doing work and you want them to log when they're done, and because logging (due to file system hiccups) can block, it's a good idea to send-off the logging function.

jonahbenton23:01:32

await with agents is sometimes necessary but should be unusual- better to use something like core.async when that kind of coordination is necessary

jonahbenton23:01:29

anyway- hope that's helpful. good luck!