Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re^5: How to create thread pool of ithreads

by elf_firein (Novice)
on Jan 29, 2009 at 14:47 UTC ( #739932=note: print w/ replies, xml ) Need Help??


in reply to Re^4: How to create thread pool of ithreads
in thread How to create thread pool of ithreads

I want to avoid the time & overhead taken by system to create DBI connection on the fly. Instead of creating DBI connection on the fly if it is managed from already created pool of DBI connections we can speed up the operation. It is my thinking from JDBC pool concept. Is it helping to DBI concept with perl?


Comment on Re^5: How to create thread pool of ithreads
Re^6: How to create thread pool of ithreads
by BrowserUk (Pope) on Feb 02, 2009 at 07:50 UTC
    Instead of creating DBI connection on the fly if it is managed from already created pool of DBI connections we can speed up the operation.

    Sorry for the delay in reponding, there is a lot to say about this, and much of it I have no first hand experience of.

    1. If your intent is to talk to the database concurrently, via DBI, from multiple threads, be aware that module still suggests that using it in conjunction with threads is still not supported.

      However, there are some signs of light.

      • Some DBD drivers (used in conjunction with DBI), particularly pure-Perl DBD drivers, are known to work.

        But the onus is on the user to a) use the pure-Perl versions; b) check that the underlying, vendor-provided C-libraries used by the DBD/database in question are themselves thread-safe.

      • DBIx::Threaded may allow you to use some other DBD drivers safely?
    2. That said, all DBD drivers, pure-Perl and otherwise are safe to use with threads, if you only call then from one thread.
    3. If your are modifying the same table(s) with all your queries, including those that you are hoping to run in multiple threads, there will likely be no advantage to issuing those queries concurrently--and it may well degrade your performance.

      The reason

      The database itself will often, of necessity, serialise concurrent queries affecting the same table(s), as it will need to lock the table(s) (including foriegn key dependancy tables), until a transaction is completed or rolled back.

      The situation may be improved if the database supports and is using record (tuple) locks, but even then, if the query can affect (require updates to), one or more indexes, it may still need to serialse the queries.

    The upshot is that it often makes sense to serialise your queries yourself.

    • Either by using queues to pass the queries/results to/from a single threads dedicated to talking to the DB.
    • Or, by serialising (semaphoring) access to a global DB handle.
    • >Or, depending upon the structure and nature of the queries your application issues, pre-creating statement handles and then serialising access to them.

    Its a complex field and you would probably get better answers going to the DBI forums and describing your application requirements in more detail.


    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://739932]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (9)
As of 2014-08-30 17:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (293 votes), past polls