You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Knut Anders Hatlen (JIRA)" <ji...@apache.org> on 2009/11/17 13:42:39 UTC
[jira] Commented: (DERBY-4447) Add internal block mechanism to
reject new database connections
[ https://issues.apache.org/jira/browse/DERBY-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778845#action_12778845 ]
Knut Anders Hatlen commented on DERBY-4447:
-------------------------------------------
The thread on derby-dev mentions two use-cases where it might prevent a race condition: upgrading and re-encrypting the database. A similar race condition might occur when initializing replication. One normally copies the database from the master to the slave, and then boots the slave database with startSlave=true. If a client attempts to connect to the slave database before startSlave has been invoked, the slave db will be booted and get out of sync with the master. In such a situation, the slave db must be dropped and copied from the master again.
> Add internal block mechanism to reject new database connections
> ---------------------------------------------------------------
>
> Key: DERBY-4447
> URL: https://issues.apache.org/jira/browse/DERBY-4447
> Project: Derby
> Issue Type: Task
> Components: Miscellaneous
> Affects Versions: 10.6.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Attachments: DatabaseAccessBlocking_r2_0.txt
>
>
> When performing certain database operations, it would be useful if Derby
> automatically blocked new connections to the database. Examples of such
> operations are dropping a database and shutting down a database.
> The block access feature would allow for:
> - More graceful shutdowns.
> New connections are rejected, and one could also implement a feature
> for waiting until all existing connections are disconnected.
> - Better error reporting for the clients.
> Instead of getting potentially "random" exceptions, a more
> well-defined set of exceptions can be expected. For instance, getting
> messages about NullPointerExceptions, container X not found,
> and database boot failed should occur more seldom (if at all). Instead the
> clients will get one of the following messages:
> * Database not found (only if the database is dropped).
> * Shutdown exception (comes in two flavors).
> * Access blocked due to reason X.
> See the thread http://markmail.org/message/ik7zgxsizg6gnyw6 (posted on derby-dev).
> Also, see the attached spec.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.