db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From pferraro <p...@columbia.edu>
Date Sat, 23 Jun 2007 19:11:02 GMT

Pardon me for butting into this thread, but stumbled upon it while googling
and wanted to correct a misunderstanding...

In the following code:

	// If any databases failed, while others succeeded, deactivate them
	if (!exceptionMap.isEmpty())

Kurt, handleExceptions() does not necessarily deactivate the failed
The base implementation does, but this is overridden by both the statement
and result set proxy objects.  When the failure occurs while executing some
SQL statement, for example, we use the Statement proxy's implementation of

	public void handleExceptions(Map<Database, SQLException> exceptionMap)
throws SQLException
		if (this.getAutoCommit())
			// If auto-commit is off, give client the opportunity to rollback the
			// ...

When auto-commit is off (i.e. this is a transactional statement) then we
stack and throw the caught exception(s).  The client code then has the
opportunity to rollback the transaction.  Unfortunately, if the statement
was an insert statement, then retrying the statement would fail with a
duplicate key exception on the database that previously succeeded.

HA-JDBC author

Bernt M. Johnsen wrote:
>>>>>>>>>>>>> Kurt Huwig wrote (2007-06-19 12:34:38):
>> Am Dienstag, 19. Juni 2007 schrieb Bernt M. Johnsen:
>> > >>>>>>>>>>>> Kurt Huwig wrote (2007-06-19
>> > > 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

View this message in context: http://www.nabble.com/REPLACE-INTO-INSERT-IF-NOT-EXIST-tf3944796.html#a11269314
Sent from the Apache Derby Users mailing list archive at Nabble.com.

View raw message