db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Blocking new connection requests in Derby
Date Tue, 10 Nov 2009 13:37:51 GMT
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.


View raw message