... permanently holding a single database connection open is a Bad Idea(tm). Some downsides:
- your code is inherently single-threaded.
I have not noticed any single-thread limitation. I have a singleton (only one instance) database class. It has the one Connection as an instance variable which is set when the class is constructed at server startup. Multiple threads call the methods in this database class.
Each call to one of the database methods prepares its own PreparedStatement from the one Connection, and closes the PreparedStatement before returning. (I would have avoided that pattern of preparing a PreparedStatement on each method call, since it seems wasteful in my limited knowledge. But if I recall correctly I got the pattern from James, where I gather it works well enough, and I have not had reason to change it in my code.)
Anyhow, I have the impression that the Connection keeps track of its many individual PreparedStatements, like a mama knows her children apart, and never mixes up their interactions. Do you think it might? I've never noticed any jumbling of data.
I think I've got the necessary synchronization, pertaining to the reading and setting of database data, handled higher up in my code. But maybe there is some database programming issue here which I need to learn.
- if you restart your db server, you get a failure in your app.
Yes! This one has hit me over the head. You've helped me see which direction I need to go to fix it.
... Database connection pools are pretty prevalent, even most JDBC3 drivers have something bundled. I would really encourage you to look into using one.
Thank you, Serge. I've got work to do.
Rich
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
