db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Clean derby shutdown - shutdown a db so no recovery needed on startup
Date Wed, 15 Apr 2009 22:11:07 GMT
Does the following mean that you plan on having multiple machines access 
a shared on disk image of derby that is shared among the machines? 
Derby can't support this configuration as it depends on the JVM 
coordinating access and in this case one JVM is not going to know 
another JVM on a different machine is accessing the db.  If so, derby 
cannot prevent concurrent access to the db, and if concurrent access is 
allowed it is very easy to end up with a corrupt db in this case.  This 
can even happen in cases where no update operation is performed by the 
access.

Derby has definitely not been designed to perform well for a single 
operation per boot.  The assumption is boot once, and then single 
connections come and go, with many derby implementation doing a single
operation per connection (best with connection pooling).  In this case
a cache is left around so that each query does not have to pay the I/O
for the various system catalog lookups necessary for the queries.


Nick Puz wrote:
> Hi Jørgen, 
> Thanks for the quick response. Due to our planned derby usage pattern (open derby, do
something for a user request, close derby) this is more of an issue. This usage is done so
that any mid-tier box can handle client requests and access the derby db on a nas/filer. I
notice the following writes/fsyncs in a read only test, are they all due to the commit log
record or is there another cause of the writes to log ctrl files: 
> 

Mime
View raw message