Specifically, is it okay to have a long-lasting statement handle, such as that you create it when your program starts up and keep it around until your program quits, so every actual use is just an execute()?
Or do statement handles hold on to limited database server resources such that it is best to have them for as little time as possible, meaning to have all of your execute() as close as possible to the prepare() in the program execution?
My question mainly applies to the DBD modules that use real database-implemented prepared statements, and not emulated ones that don't actually do anything until execute() time. In the latter case, I know that no resources are held on to.
I have a decision to make as to whether I should try, with a long running program such as would run under mod_perl, to front-load all the prepare() to when a process or thread starts, so each page request only has execute().
The other option is to run them close together more or less like do() does.
More broadly speaking, I wonder if it is possible to do prepares prior to opening a database connection, so they can be reused through multiple connections? Or if the system was never designed for this sort of thing?
If I have a choice to do either, it might be useful to add an information function to the DBI interface that reports whether the current $dbh will use actual or emulated prepared statements. Unless one already exists.
Thank you. -- Darren Duncan
