[Biojava-l] Changable and rollbacks

[Matthew Pocock]

Hi Dan,

I agree - preChange should do nothing except potentialy throw a 
ChangeVetoException, and postChange should be the method used to update 
state. However, if I have 5 sequences, each of which I am going to add 
some features to, and want to either add all features to each sequence 
or do nothing, there is currently no way to do this. We can process each 
feature addition individualy, but we can't invoke preChange for every 
listener for each change before *any* of the changes are executed, then 
perform *all* changes and then invoke all postChange methods.

Mark, is this what you wanted to be able to do?

M

Forsch, Dan wrote:

> 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
>>