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, 17 Nov 2009 10:35:47 GMT
Kristian Waagan wrote:
> 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" ;)

I created DERBY-4447 to track this, and I trimmed down the initial spec 
and attached it to the Jira issue.

I also wrote a test that demonstrated that we are vulnerable to race 
conditions during hard-upgrade. Per today, the user have to ensure 
exclusive database access by using means outside of Derby itself. This 
is a separate issue, and the drop database functionality can be 
implemented without being held up by it.

As a side note, Derby blocked concurrent access from two different 
classloaders, which is good. The remaining issue then is 
applications/frameworks where you can hot-swap the version of the Derby 
jars/classes. If you plan to upgrade both the jars and the database 
format in such an environment, you must take care to make sure the 
database actually gets upgraded. An upgrade request issued against a 
booted database will fail silently, giving the user the impression that 
it worked.


> Regards,

View raw message