Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Date: Tue, 10 Nov 2009 15:52:53 +0100
From: Kristian Waagan <Kristian.Waagan@Sun.COM>
Subject: Re: Blocking new connection requests in Derby
In-reply-to: <4AF96CAF.1030608@sun.com>
Sender: Kristian.Waagan@Sun.COM
To: derby-dev@db.apache.org
Message-id: <4AF97E45.3010902@Sun.COM>
References: <4AF428CB.7060705@Sun.COM> <4AF871DA.9010203@sun.com>
 <4AF96849.6060709@Sun.COM> <4AF96CAF.1030608@sun.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090818)

Rick Hillegas wrote:
> Kristian Waagan wrote:
>> Rick Hillegas wrote:
>>> Thanks for writing up this spec, Kristian. If I understand 
>>> correctly, you are proposing a mechanism for rejecting new 
>>> connections to a database to handle the following situations:
>>>
>>> 1) Eliminate race conditions and ugly, puzzling diagnostic messages 
>>> during database shutdown and database deletion.
>>>
>>> 2) Protect extended database maintenance from corrupting, concurrent 
>>> access.
>>>
>>> It seems to me that (1) is a very reasonable use case and probably 
>>> doesn't need any additional api: by default a database 
>>> shutdown/deletion should prevent other users from connecting and 
>>> should, in fact, kick out all other users.
>>>
>>> Can you give some use-cases for situation (2)?
>>
>> Hi Rick,
>>
>> Situation (2) arises when doing maintenance operations, and is 
>> basically an alternative to shutting down an application or the 
>> database server. The goal is to ensure no other connections are made 
>> to the database. This include boot- and creation-attempts. Some 
>> use-cases:
>> a) You simply want to block out all users without shutting down the JVM.
>> b) You need to hard-upgrade the database.
>>    In this situation, you don't want anyone to boot the database 
>> before you (after it has been shut down).
>> c) You need to (re-)encrypt the database.
>>    Same as above.
>>
>> The most problematic situation today may be when you have a network 
>> server with several active databases, say one for each of your 
>> customers. How do you currently block access to one of the databases 
>> without affecting the others?
>> We don't have system privileges (yet), so I can only think of using 
>> the Java security manager, moving the database away (might be very 
>> costly for large databases) or possibly disabling users at the 
>> system-wide level. None of these mechanisms are easy to use with the 
>> current level of tooling.
>>
>> Also, by throwing a known exception stating the database has been 
>> temporarily blocked, properly written applications can detect this 
>> and simply try to connect again after waiting for a while.
>>
>> Finally, after thinking more about it, this feature would need a 
>> different API to ensure  *exclusive* access to the database. The 
>> reason is that Derby has to boot a database to determine if the user 
>> is the DBO (or a DBA). The rejection should happen prior to booting 
>> the database. I have some thoughts about this, but let us first 
>> discuss the need for such a feature.
>> Just to be clear, the spec would need rewriting to be accurate for (2).
>>
>>
>> I agree (1) and (2) are different situations, and that (1) alone will 
>> be enough to address many issues. I don't have any problems dropping 
>> (2) if it isn't considered useful.
>>
>>
>> Thanks,
> Thanks for the quick response, Kristian. It seems to me that (2b) and 
> (2c) are similar to (1) in that they should be the default behavior. 
> My gut feeling is that (1) + (2b) + (2c) are very useful: we should 
> always freeze out other users when performing these operations. (2a) 
> is still murky to me and I would be tempted to not design a 
> user-invokable api for this until we know more about who would use it. 
> It makes sense to me to log an enhancement JIRA for (2a) but not 
> design a user-invokable api for it until a user turns up who needs it. 
> It may be that that user will have experience with a good api from 
> another database, which we could mimic.

Rick,

Your reservations sound reasonable.
I'll trim down the spec and attach it to a Jira (not yet created) for 
further review.

I'm still not sure if we can cover (2b) with default  behavior, though.
My understanding is that the database has to be shut down before you 
make the connection to hard-upgrade the database. This means that you 
have to somehow ensure nobody else can connect to the database in the 
time-window from when you shut down the database to the connection with 
the upgrade attributes is accepted. This process has to happen as two 
separate connections.

Is my understanding wrong?
You still have to load the new Derby jars to upgrade, and in most 
systems I assume this requires you to take down the application / 
server. Using OSGi may be an exception...

Let me investigate a bit more, I'll post my findings to the list. The 
problem may be "of academic interest only" ;)


Regards,
-- 
Kristian

>
> Thanks,
> -Rick