db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernt M. Johnsen" <Bernt.John...@Sun.COM>
Subject Re: REPLACE INTO/INSERT IF NOT EXIST
Date Tue, 19 Jun 2007 10:15:42 GMT
>>>>>>>>>>>> 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.

-- 
Bernt Marius Johnsen, Database Technology Group, 
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway

Mime
View raw message