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,
