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" ;)
Regards,
--
Kristian
Thanks,
-Rick
