Re: Is there some way to shut down a Derby database faster?
Trejkaz trej...@trypticon.org writes: On Tue, Jul 2, 2013 at 10:18 PM, Rick Hillegas rick.hille...@oracle.com wrote: If you simply exit the VM without requesting an orderly shutdown, then the checkpoint won't be performed. However, the cleanup performed by that checkpoint still has to be performed. It will be performed the next time you boot the database. My experience is that if you always skip the orderly shutdown, then the time required to boot the database grows progressively longer until it is intolerable. Full disclosure: I haven't tried this experiment for a long time and there may have been improvements in this area. Nevertheless, orderly shutdown is the recommended practice. Exiting the VM isn't really an option for me anyway, this is just when someone is closing the database, potentially planning to open another one. Another question along the same lines then - if I kick off the shutdown in another thread, what happens if the same database is then reopened while the shutdown is still occurring? Hi Trejkaz, I think the shutdown will continue unaffected of the other thread trying to reopen the database. The thread that tries to reopen it, on the other hand, might see all kinds of errors, like NullPointerExceptions or conglomerate not found errors. There once was an effort to make Derby more well-behaved in this use case (see https://issues.apache.org/jira/browse/DERBY-4447), but the work on that issue stalled. So for now you'll probably have to synchronize between the thread that shuts down the database and those that try to connect to the same database, so that they wait with connecting until the database has finished shutting down. -- Knut Anders
Re: Is there some way to shut down a Derby database faster?
Exiting the VM isn't really an option for me anyway, this is just when someone is closing the database, potentially planning to open another one. Another question along the same lines then - if I kick off the shutdown in another thread, what happens if the same database is then reopened while the shutdown is still occurring? It sounds like users are routinely arriving, doing work, and disconnecting, causing the database to be opened and closed. Have you considered using a connection pool in between your application layer and the database, so that the connections are retained and re-used, rather than being fully reclaimed and fully reopened? thanks, bryan
Re: Is there some way to shut down a Derby database faster?
On Fri, Jul 5, 2013 at 12:44 AM, Bryan Pendleton bpendleton.de...@gmail.com wrote: Have you considered using a connection pool in between your application layer and the database, so that the connections are retained and re-used, rather than being fully reclaimed and fully reopened? From the original post: | and when the user closes the database they expect to be able to move | the files immediately after. TX
Re: Is there some way to shut down a Derby database faster?
So if users need data after working with database give them consistent copy using backup http://db.apache.org/derby/docs/10.0/manuals/admin/hubprnt43.html#HDRSII-BUBBKUP-63476 Peter On 4. 7. 2013, at 23:17, Trejkaz trej...@trypticon.org wrote: On Fri, Jul 5, 2013 at 12:44 AM, Bryan Pendleton bpendleton.de...@gmail.com wrote: Have you considered using a connection pool in between your application layer and the database, so that the connections are retained and re-used, rather than being fully reclaimed and fully reopened? From the original post: | and when the user closes the database they expect to be able to move | the files immediately after. TX
Re: Is there some way to shut down a Derby database faster?
On 7/1/13 6:01 PM, Trejkaz wrote: Hi all. Is there some way to shut down a Derby database in a faster way? The current ;shutdown=true we're using is doing a checkpoint, which seems to be a particularly expensive operation. I can't rely on the if you don't want to do the checkpoint, just don't shut it down approach, because this won't release file handles and when the user closes the database they expect to be able to move the files immediately after. TX If you simply exit the VM without requesting an orderly shutdown, then the checkpoint won't be performed. However, the cleanup performed by that checkpoint still has to be performed. It will be performed the next time you boot the database. My experience is that if you always skip the orderly shutdown, then the time required to boot the database grows progressively longer until it is intolerable. Full disclosure: I haven't tried this experiment for a long time and there may have been improvements in this area. Nevertheless, orderly shutdown is the recommended practice. Hope this helps, -Rick
