[Biojava-l] Changable and rollbacks

[Forsch, Dan]

I would think that this is easily supported by the current model, at least
the way I understand Mark's question.  The preChange() method's signature
throws ChangeVetoException and postChange() does not.  When preChange() is
called you cannot be guaranteed that the change won't be vetoed by another
listener, so a reasonable implementation of preChange() is to veto if you
care to and do nothing otherwise.  The postChange() method is where
listeners can safely make any response to the change that has ocurred.  If
any listener has vetoed, postChange() should never be called.  Rather than
rolling back changes made too soon, you should wait until postChange() has
been called to alter the state of any listeners.

Dan Forsch, Principal Software Engineer
NetGenics, Inc.


> -----Original Message-----
> From: Matthew Pocock [mailto:mrp@sanger.ac.uk]
> Sent: Friday, May 11, 2001 4:45 AM
> To: Schreiber, Mark
> Cc: 'Biojava-L (E-mail)
> Subject: Re: [Biojava-l] Changable and rollbacks
> 
> 
> 
> This sort of thing is not easily supported with the current 
> model, but I 
> agree that it is a usefull thing to have. One way to do it 
> would be to 
> make an entity that represented the list of sequences and has a 
> commitAll style method. This would do some package-private diddling 
> inside each sequence it contains to check the prechange 
> vetoes, and if 
> successfull perform each real commit.
> 
> This does, however, require us to think again about the 
> encapsulation of 
> the pre/post change infrastructure (particularly as we may need to 
> synchronize on some resource to maintain atomicity).
> 
> All thoughts welcome.
> 
> M
>