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>
Date Tue, 19 Jun 2007 11:03:02 GMT
>>>>>>>>>>>> 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

View raw message