db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Puz <nick.de...@me.com>
Subject Re: Clean derby shutdown - shutdown a db so no recovery needed on startup
Date Wed, 15 Apr 2009 23:36:56 GMT
Hi Mike, 

I'm aware that cross jvm access is not supported so we will prevent multiple mid-tier boxes
from opening derby by other (external to derby) means (symlink based "locking", since we don't
want to use nfs file locking). 

Are there other areas of derby that you think will cause problem in the single op per boot
mode? I already ran into the bug with multiple quick open/closes (DERBY-4018) and did a very
coarse temporary fix (will do better one and post back if we end up going w/ derby), and the
other big issue is prepared statement creation (email earlier today to derby-dev list). 


On Wednesday, April 15, 2009, at 03:11PM, "Mike Matrigali" <mikem_app@sbcglobal.net>
>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 
>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: 

View raw message