Question on best practices on handling SQL database concurrency issues
I am pmapping a evaluation to a long list (which calls a
computationally intense script) from within clojure. The script
itself is designed to be completely free of concurrency side-effects.
During the evaluation, several
Isn't programming not all about cheating the computer in doing what you want
it to do? In the book programming clojure you can find an example with locks
as well.
2010/3/25 Scott sbuck...@gmail.com
Question on best practices on handling SQL database concurrency issues
I am pmapping a
id prefer best practices if possible
typically, cheating has consequences down the line
On Mar 25, 10:43 am, Joop Kiefte iko...@gmail.com wrote:
Isn't programming not all about cheating the computer in doing what you want
it to do? In the book programming clojure you can find an example with
Are the writes commutative? Since you are using pmap, I presume so. In
that case, you could funnel the writes through an agent serving as a
queue.
-Per
On Thu, Mar 25, 2010 at 9:59 PM, Scott sbuck...@gmail.com wrote:
id prefer best practices if possible
typically, cheating has consequences
Hi,
maybe you can put finished work packages into a Queue and have a
(different) thread reading them from the queue and writing them to the
database linearly. So the workers don't have to know about the
database and the DB writer doesn't have to care for the computation.
Since you can't write to
I would suggest using a more concurrency-aware database. I've had luck
with H2 (http://www.h2database.com/). It supports mixed local and
remote connections in a thread-safe manner. Additionally it supports
simple clustering, sounds like you could have use for such.
Best Regards,
Joonas
--
You
Is it as simple as moving to a better database, such as
mySQL?
PostgreSQL is considerably better (even than MySQL, which still uses
locks AFAIK)
for anything concurrent. The PostgreSQL is using multiple version
concurrency (MVC)
approach - the same approach the clojure STM is using.
The
thanks for your suggestions
two clear options 1) agents and queued transactions 2) MVC enabled
databases (postgresql, h2 (neat project))
Ill try the first option and see how it scales, and worst case move to
the second
Thanks again
Scott
On Mar 25, 12:47 pm, prhlava prhl...@googlemail.com
