Re: Using a single database handle or multiple handles

Does it matter either way?

Of course it matters, but that's application specific.

What zwon says, and then:

If your subroutines running time is so long that the overhead of setting up the database connection is negligible, you would delegate setting up the handle to each subroutine.
If your subs comprise transactions and you need to close the connection after each, you would let the sub set up the connection.
If you have many small operations, scattered over subroutines each running for a short time, you would pass the handle into the subs.
If database stuff is merely an initializing task, or a side aspect of your application, you might want to encapsulate the database stuff into a subroutine.
In a single threaded architecture, you could use one handle. In a multithreaded environment, you'd create a handle in subroutines which comprise a thread.

Then you might have long running tasks. Could there be time-outs? Does your application fork? and so on...

Comment on Re: Using a single database handle or multiple handles

Replies are listed 'Best First'.
Re^2: Using a single database handle or multiple handles by erix (Prior) on Oct 11, 2012 at 15:32 UTC
If your subs comprise transactions and you need to close the connection after each, you would let the sub set up the connection. This seems a somewhat strange procedure, or construction. Transactions are committed or rolled back by telling the database to COMMIT or ROLLBACK (and dbi can do either), not by closing the connection...	[reply]