db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4447) Add internal block mechanism to reject new database connections
Date Tue, 17 Nov 2009 12:42:39 GMT

    [ 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:
>            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.

View raw message