Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <42B2F180.2060000@sbcglobal.net>
Date: Fri, 17 Jun 2005 08:51:28 -0700
From: Mike Matrigali <mikem_app@sbcglobal.net>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Derby Discussion <derby-user@db.apache.org>
Subject: Re: Is it possible to force read-only mode?
References: <42AF850F.4070908@nuix.com.au>
 <x1ofpsuohrhk.fsf@atum11.Norway.Sun.COM> <42B10A3C.6050605@nuix.com.au>
 <42B1B74D.6010505@sbcglobal.net> <42B22F41.1000805@nuix.com.au>
In-Reply-To: <42B22F41.1000805@nuix.com.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I believe the problem is that derby just does not currently support
the type of read only that you want.  It supports read only
connections, but not a database marked read only.  It uses the lock
to coordinate with other connections which may try to access the
database.

I believe if one were to implement some sort of admin command which
marked a database as read only in the system catalogs somehow, and
made sure write connections figured it out and failed very early
in the boot process you could get what you are looking for.  Things
to worry about:

1) When marking the database, you need to worry about outstanding
    changes to data pages still in the cache and out standing log
    records in the log before the most recent checkpoint.  Otherwise
    booting the database may require writes to data pages and or
    log files and as soon as 2 JVMs are writing to data pages or log
    files the db is almost sure to be corrupted.

2) Some read only queries still require temporary files, sort is the
    most obvious example.  Current Derby support of readonly db's still
    allow these temp files, and assume that even if the derby db is
    located on some truly read only media like a CD, that the application
    will set a separate writable temp space.  The names of the files
    in the temp space are coordinated within a single JVM, but if 2 JVMs
    accessed the same db on the same machine with the same temp space
    it would not work as currently implemented.


Daniel Noll wrote:
> Kathey Marsden wrote:
> 
>> Daniel Noll wrote:
>>
>>  
>>
>>> We have considered this option and discarded it for the time being.
>>>
>>> Basically, our application isn't client-server, and probably won't be
>>> for a while... probably a long while.  We just wanted to implement a
>>> cheap way for two people to look at the same database through our app
>>> at the same time, possibly on different machines (the data would be
>>> accessible via NFS, CIFS, or whatever.)  Since no user needs to modify
>>> the database (and doing so would be bad, for various reasons) I
>>> figured that read-only mode could be used to do this.
>>>
>>>   
>>
>>
>> I don't have real clarity on your configuration but I think the embedded
>> server model might be appropriate for what you are doing. Your app
>> continues to use embedded but you start network server in the same jvm
>> to allow access by external jvms.
>> You can probably test this very quickly to see if it is what you need by
>> setting the property derby.drda.startNetworkServer=true  in your
>> derby.properties file and starting up your application.  Then you can
>> safely connect with ij  from another JVM.
>>  
>>
> My problem is something like this (I'll use the standard naming scheme
> for arbitrary users)...
> 
> Suppose that Alice and Bob both want to open a database located at
> file://server/data/case-001/Database .
> 
> You're saying that Alice's app can simply start an embedded server and
> that Bob's app can connect to that server.  The problems with this, as
> we see it, are:
> 
>    1. Bob's app has no way to figure out which host on its subnet is
>       running the server.
> 
>    2. Even if the app knows which host is running the server, it has no
>       easy way to correlate the file it wants to open with a database
>       URL for remote connection.
> 
>    3. If Alice decides to close her app, it will affect Bob's
>       connection, and we'll need sophisticated logic to make Bob's
>       app create a new embedded server, which Alice will then need
>       to connect to when she fails to connect to the database.
> 
>    4. The situation becomes even more difficult if there are more
>       than one app running on the same host, which happens on
>       terminal server setups.  Alice might open up one database and
>       Bob wants to open another, and both of these need to start
>       the embedded server in case Charlie wants to open either one.
> 
>       Even if we ran each server on a different port somehow, which
>       port does charlie connect to?
> 
>    5. The two hosts might not even be on the same network segment, and
>       thus would be unable to intercommunicate at all.
> 
> 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?
> 
> Daniel
>