db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Thalamati <suresh.thalam...@gmail.com>
Subject Re: Is it possible to force read-only mode?
Date Mon, 20 Jun 2005 18:46:21 GMT

I tried the following steps to create a simple readonly DB on file 
system it seems to  work fine for  me.

 1)  shutdown the DB with no pending transaction (this step is same for 
jars also), to avoid rollbacks during recovery on a readonly  system.
 2) disable(deny)  write permission  for  all the files/directories   
under databases directory for the user id. that  is starting  the DB.    
 3) derby  store seems to recognize that  database is read only if is it 
unable to create/modify files under database directory.
 4)  start  each JVM that access the database with  property 
derby.storage.tempDirectory (D"derby.storage.tempDirectory=c:/temp/x2") 
to  specify  different
      temp directory for each instance ,  for the queries to  create 
temporary files in different directories.
 
 My guess  is , you are not disabling the write permissions correctly 
for the database directory  on  the  OS. Otherwise it would not be able to
 boot in the in the write mode at all,  because it needs to crearte lock 
files,  and  log files ..etc to do anything.


Thanks
-suresht


Daniel Noll wrote:

> Daniel John Debrunner wrote:
>
>>>   5. The two hosts might not even be on the same network segment, and
>>>      thus would be unable to intercommunicate at all.
>>>   
>>
>>
>>
>> If that's the case then even NFS won't work, right?
>>
>>  
>>
> Suppose your NFS server is available as 192.168.1.10 and 
> 192.168.2.10.  Hosts on 192.168.1.0/24 and 192.268.2.0/24 can't access 
> each other, but they can _certainly_ access the fileserver.
>
>>> It seems like this problem wouldn't exist at all if Derby didn't try to
>>> lock the database.  My real question is, if I want to open it in
>>> read-only mode anyway, what business does it have locking it from other
>>> readers?
>>>   
>>
>>
>> Because the readers wouldn't see a consistent, correct view of the
>> database, and may have unpredictable failures. Readers in this case are
>> a separate JVM running Derby opening the files in read only mode that
>> are in use by another JVM running Derby. This mode is not supported.
>>
>> It is not supported because the active Derby engine does not write every
>> update to disk as soon as it happens. It uses a write-ahead logging
>> (WAL) system which ensures transaction durability without requiring all
>> data changes to be made to disk. This is a performance benefit, if a
>> transaction modifies, say, five rows then with a WAL scheme only one
>> disk i/o is required to commit the transaction. Without WAL there would
>> be up to five i/o's to commit.
>>
>>  
>>
> If someone was going to write to it, it wouldn't be read-only, would 
> it?  I did say from the beginning that I wanted to open it in 
> read-only mode.
>
> I don't understand why this is such a big issue for a filesystem, when 
> it allegedly works fine when the database is in a JAR file.  Where is 
> your inconsistent state in that case?
>
> Daniel
>



Mime
View raw message