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.
Thanks,
-Rick
