db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kurt Huwig <k.hu...@iku-ag.de>
Subject Re: REPLACE INTO/INSERT IF NOT EXIST
Date Tue, 19 Jun 2007 10:46:03 GMT
Am Dienstag, 19. Juni 2007 schrieb Bernt M. Johnsen:
> >>>>>>>>>>>> Kurt Huwig wrote (2007-06-19 12:34:38):
> >
> > Am Dienstag, 19. Juni 2007 schrieb Bernt M. Johnsen:
> > > >>>>>>>>>>>> Kurt Huwig wrote (2007-06-19
10:46:09):
> > > >
> > > > Unfortunately, both are not an option for me due to the way HA-JBDC
> > > > works: it sends every SQL-update statement to every node. If it
> > > > succeeds on one node and fails on another node, then the failing
> > > > node is believed to be malfunctioning and taken out of the
> > > > cluster.
> > >
> > > As I anduerstand the HA-JDBC docs, an SQLException will not lead to
> > > the assumption of a failed node. An SQLException will trigger a
> > > mechanism which cheks wether the node is functioning (via. some
> > > trivial SQL query). See:
> > > http://ha-jdbc.sourceforge.net/doc.html#Failed+Database+Nodes
> > >
> > > Thus you may safely insert a record and ignore the duplicate key
> > > exception.
> >
> > This documentation is somehow misleading. It will deactivate the node
> > immediately, if it fails a "VALUES (1)" (for Derby dialect). But this is
> > only to determine, if the statement is wrong or the database. After the
> > statement has been executed on all databases, this happens:
> >
> > net.sf.hajdbc.sql.SQLObject.java:443
> > 		// If any databases failed, while others succeeded, deactivate them
> > 		if (!exceptionMap.isEmpty())
> > 		{
> > 			this.handleExceptions(exceptionMap);
> > 		}
> >
> > and handleExceptions() deactivates the failed node.
>
> Ok, I see. I assumed that if HA-jdbc got an SQLException from one of
> the nodes, the complete transaction was rolled back on all nodes. I
> would say that such lack of transactional behaviour is a serious
> weakness in HA-Jdbc.

I guess this is intentional, as you generally don't want your transactions to 
fail if one of the nodes goes bad. I mean this is the whole point of having a 
cluster, right?
-- 
Kurt Huwig
GnuPG 1024D/99DD9468 64B1 0C5B 82BC E16E 8940  EB6D 4C32 F908 99DD 9468

Mime
View raw message