db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: Blocking new connection requests in Derby
Date Tue, 10 Nov 2009 13:19:05 GMT
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,
> -Rick
> Kristian Waagan wrote:
>> Hello,
>> When working on the feature of dropping databases (in-memory 
>> primarily), it became apparent that the possibility to temporarily 
>> block incoming connection attempts would be very useful.
>> I have started on a spec for this feature. Today I was supposed to 
>> continue working on it, but got lost in code trying to write a 
>> prototype to verify some claims instead :)
>> I'm choosing to post it now anyway to see if I get any feedback on 
>> whether this feature would be useful in other scenarios. If so, there 
>> may be new requirements not included in the current spec.
>> Verification of what I have written about authentication and 
>> authorization is also definitely required.
>> If I get positive feedback, I can create a Jira and post a prototype 
>> shortly after. This should allow us to make progress after our 
>> initial discussion here. If you want to have a quick look at the test 
>> I threw at Derby (currently doesn't work because all the required 
>> code hasn't been posted, specifically the drop database code), see 
>> the class DropWhileConnectingTest in patch 1a attached to DERBY-4436.
>> As a side note, most of my work so far has been with the embedded 
>> driver. I suspect getting the network client to behave as well as the 
>> embedded driver may be harder.
>> Regards,

View raw message