There are a number of issues that for the most part are distinct
1) Commit a transaction when you're sure you don't have to abort (or
when you need to release resources).
2) Close the connection when you no longer need it/it is about to go out
of scope.
3) Shutdown a database to
a) speed up the next boot (as the db does not have to recover from
its log)
b) to release the database (files) for another jvm
4) Shutdown the Derby engine to release resources to the rest of your
application when you don't need access to any databases.
On 04/07/2014 03:49 AM, Chux wrote:
Hello George,
Thanks for your comment. This situation however is, I'm using java DB as
an embedded mode.
Best,
Chux
On Mon, Apr 7, 2014 at 3:02 AM, George Toma <[email protected]
<mailto:[email protected]>> wrote:
Hi Chux,
In my opinion the example from app. referred at commit the
transaction OR close the connection ( a connection could be
transacted too ), and not to shutdown the db. If the business rule
specifies that the db. needs to be shutdown when the app. is
shutdown, then so be it.
Normally the db is not shutdown, not even when the app is down.
Cheers,
George
On Sunday, April 6, 2014 7:14 PM, Chux <[email protected]
<mailto:[email protected]>> wrote:
Hello guys,
I read in a sample app that you've got to shutdown a database. I was
just confused if you need to shut it down on every connection
transaction or just shut it down on application close, in my case a
desktop applicaiton.
Best,
Chux
--
Regards,
Dyre
