>>>>>>>>>>>> Kurt Huwig wrote (2007-06-19 13:46:03): > Am Dienstag, 19. Juni 2007 schrieb Bernt M. Johnsen: > > 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?
No, I wouldn't say that. The point of an HA cluster is to have several instances of your data in an up-to-date and consistent state in case one of the nodes fail, allowing you to continue operations after the failure. Failure of the whole transaction when one of the nodes fail during the transaction is quite normal for clustered solutions. The application should then be written from the fact that all transactions might fail, and the transaction has to be retried if it fails. (This actually applies to all applications using some interface to an SQL database). JDBC 4.0 has defined subclasses of SQLException which enables an application to handle cases like this. If a node fails and causes the running transaction(s) to fail, but the cluster is working after the failure (with one less node, though) an SQLTransientException (or a subclass) should be thrown and the application may assume that the transaction can be retried. If an SQLNonTransientException is thrown, there is noe use to retry the transaction. -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway
pgpRfbqm3WUpo.pgp
Description: PGP signature
