>>>>>>>>>>>> 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
pgpjPLunFPm7x.pgp
Description: PGP signature
