This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
Hello. I have this scenario: A java process will run every minute. This process read a file, make alot of logic with the file and then insert and update records of a table in a data base. Since it is a process (a daemon) and it doesnt have a container (like tomcat) to store a connection pool, how would i mange the DB connection? I think its a bad idea to open and close a connection every minute that my process runs.
Any suggestions??? Thanks a lot.
If this java process starts, does db work, then terminates, you have no choice but to establish a new connection each time it runs and connection cannot be held open across process boundaries.
You might consider converting it into an app deployed to a container and using a timer service, such as Quartz, to start the app every minute. Then the app could make use of the connection pool provided by the container.
Before you start down that road, consider the cost of opening a database connection once a minute. It's probably minuscule compared to a minute. Don't just "think" that it's a bad idea, investigate how bad it actually is. You may save yourself a lot of work.
Paul's advice is good advice, heed it before you go any further.
I don't think a WAR is a goo idea, probably an EJB would be better.
However, you will then have traded the cost of establishing a database connection every minute with the cost of continuously running an app server which will definitely have larger memory requirements than your app.
Another possibility: instead of firing off your app every minute, why not have the app run continuously, pausing a minute between database accesses. Here is pseuduocode: