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,
--
Kristian
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,
