Design Problem with VetoableChangeListener

Question

Hello i have a problem with the design of a VetoableChangeListener:

I implement the VetoableChangeListener interface to listen changes of a property in a model class, when the model fires the

vetoableChange(PropertyChangeEvent evt) throws PropertyVetoException

i try to save the change in a DB, which could fail (by a SQLException, for example), if it fail's i throw an PropertyVetoException to revert changes in the model, but...

the model is delegating in a VetoableChangeSupport (JDK class), which when receive an PropertyVetoException catches it and notifies the revert to ALL the VetoableChangeListener ,with the oldValue/ newValue interchanged (later it rethrows the exception), so that the event comes to my class again and i try to save in DB again, etc...

I have an workarround which is the model NOT changes until nobody throw an PropertyVetoException, so that in the VetoableChangeListener i FIRST check if the data i going to save in DB is NOT equal to the data in the model, if it's equal i simply ignore the change.

Is there another better workaround?

P.D Sorry for my bad english

Answer 1

You should check the Vetoable change before you change the model, not after...

ie: if there is a problem, the model is not changed, not revert the model if the change was wrong

Answer 2

To:timyates

Thats exactly what i do, i recive the event, try to update the DB, and it fails, i throw the exception vetoing the change, so that the model is not updated, but the problem is that the VetoableChangeSupport notifies me my own veto, entering in a bucle if i not do the workaround that i explain in the question

Answer 3

Your "workaround" is not really a workaround but in fact sounds like the proper solution to me: confirming that there is in fact a change for the current state of the object prior to attempting to "change" the persisted version. This will also be much more efficient (database access is expensive).