Wiggins has asked for the wisdom of the Perl Monks concerning the following question:

I have read through DBI documentation (referencing Perl 5.7 and 5.8) saying that DBI + manufacturers code are not thread safe; in 2003. Has the situation changed in the last 10 years?

I am looking at doing a threaded Producer /Consumer system, feeding into a PostgreSQL database. Does anyone have recent experience with that?

It is always better to have seen your target for yourself, rather than depend upon someone else's description.

Replies are listed 'Best First'.
Re: ?Thread safe DBI? any updates?
by BrowserUk (Patriarch) on Feb 15, 2013 at 18:05 UTC
    I am looking at doing a threaded Producer /Consumer system, feeding into a PostgreSQL database.

    The simple, conservative rule here is only have one thread accessing the database. This is pretty much guaranteed to work okay.

    From experience, I can tell you that DBD::PgPP works fine from multiple threads. By hearsay, I believe that DBD::Pg is also threadsafe.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
Re: ?Thread safe DBI? any updates?
by Anonymous Monk on Feb 15, 2013 at 17:49 UTC

    Has the situation changed in the last 10 years?

    The documentation has changed :)

[reply]
Re: ?Thread safe DBI? any updates?
by locked_user sundialsvc4 (Abbot) on Feb 15, 2013 at 19:06 UTC

    If you are going to multi-thread queries, also check that query processing actually does occur in parallel.   This would not only mean that the queries are being effectively handled as separate streams, but also that the queries themselves are capable of executing without contention with one another .. transaction isolation and so-forth.   And that it is actually faster, given what you are actually trying to do and actual conditions.

    Lately, I have switched more-and-more to simple programs that can be run independently of one another, i.e. as entirely separate processes, launched for example through a batch or workload-processing system.   With this approach, there is of course no concurrency-issue within the application that must be considered, and the workload manager can tune the situation very directly:   just launch as many copies as you need.   Naturally you have to have a reliable and not-too contentious way to parcel up the work.

      Lately, I have switched more-and-more to simple programs

      Care to post one of those simple programs? Or one of the threaded programs it replaces?

      Or indeed, post any single piece of runnable code by which we might collectively gauge the efficacy of the coding prowess that sits behind your home-brew wisdom?

      Because on the strength of the utter guff you repeatedly spew into any and every thread on threading; I seriously doubt that you have ever written a threaded program in your life. To date, you have yet to post a single code solution, on any subject, anywhere on this forum. You are a fantasist. Nothing more nor less.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

Back to Seekers of Perl Wisdom