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.