Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <275355227.1203567463406.JavaMail.jira@brutus>
Date: Wed, 20 Feb 2008 20:17:43 -0800 (PST)
From: "V.Narayanan (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-3428) Doing a replication failover should
 shutdown the database and the connection should no longer be available
In-Reply-To: <779649975.1203316954741.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

V.Narayanan updated DERBY-3428:
-------------------------------

    Attachment: Derby3428.stat
                Derby3428.diff

Thank you for the suggestions Jorgen on the reply to the email requesting more information on the
handleException method in EmbedConnection. Following the suggested steps I found that throwing an exception with a Database severity does shutdown the database, but, only if it is not frozen :-/.

During failover, before flushing the log records from the master to the slave, we freeze the
database in question to prevent any more transactions from committing, since, these would never
be conveyed to the slave. Allowing them to proceed would result in inconsistency. We do not
unfreeze before throwing a database severity exception to cause a shutdown in case of a 
successful failover. This causes a hang when we try to shutdown.

The obvious workaround was to unfreeze and then throw the exception. But this exposes a window,
between unfreezing and throwing the exception when I suspect there is the danger of transactions
commmiting. But the exception that is thrown upon failover should alert the clients that the
danger of the previous transaction being lost exists.

I am submitting a patch using the workaround above and hoping that the community can advice me
more here.

During the course of developing this patch I observed that we should have a tearDown method on
the transmitter that the log shipper could call when it does a stopShipment. This would basically
bring down the socket and the associated streams. I am *not* submitting this as part of this patch. 

Also the socket needs a timeout for reads on the InputStream obtained from it but I guess there is a 
JIRA for that already.

> Doing a replication failover should shutdown the database and the connection should no longer be available
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3428
>                 URL: https://issues.apache.org/jira/browse/DERBY-3428
>             Project: Derby
>          Issue Type: Bug
>          Components: Replication
>    Affects Versions: 10.4.0.0
>            Reporter: V.Narayanan
>            Assignee: V.Narayanan
>         Attachments: Derby3428.diff, Derby3428.stat
>
>
> Oystein says (as part of comments in Derby-3205)
> After executing a failover, I am told that the database is shut down, but I still able to use the connection to access the database:
> ij version 10.4
> ij> connect 'jdbc:derby:masterDB;user=oystein;password=pass';
> ij> call syscs_util.syscs_freeze_database();
> 0 rows inserted/updated/deleted
> ij> connect 'jdbc:derby:masterDB;user=oystein;password=pass;startMaster=true;slaveHost=localhost';
> ij(CONNECTION1)> call syscs_util.syscs_unfreeze_database();
> 0 rows inserted/updated/deleted
> ij(CONNECTION1)> connect 'jdbc:derby:masterDB;user=oystein;password=pass;failover=true';
> ERROR XRE20: Failover performed successfully for database 'null', the database has been shutdown.
> ij(CONNECTION1)> select * from t;
> I
> -----------
> 1
> 2
> 3
> 4
> 5
> 6
> 7
> 8
> 9
> 10
> 10
> 11 rows selected
> ij(CONNECTION1)>

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.