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 Mon, 09 Nov 2009 19:47:38 GMT
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)?

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,



Mime
View raw message