[Biojava-l] Changable and rollbacks

[Dickson, Mike]

Is there a datastore under the hood?  Normally this sort of thing would be
handled with transactional behaviour.  You really want atomic behaviour
across a set of updates.  Even if there isn't a database, you could still
handle the transactional updates by implementing a transactional interface
and delaying the commit until the whole transaction commits.  That is, you'd
make method calls on the object as normal and when the entire update is
completed commit the transaction.  All the objects involved in the
transaction would then actually commit the changes or rollback togethor.

Implementing such a commit strategy is hard (but possible).  In the corba
world the notion of a transactional object and transaction coordinator is
used to provide it.  I believe the comparable interfaces in java are in JTA.
Ideally you'd get a database to do all the dirty work for you.  Is that
possible?

Mike

> -----Original Message-----
> From: Schreiber, Mark [mailto:mark.schreiber@agresearch.co.nz]
> Sent: Monday, May 14, 2001 4:49 PM
> To: 'Matthew Pocock'; Forsch, Dan
> Cc: Schreiber, Mark; 'Biojava-L (E-mail)
> Subject: RE: [Biojava-l] Changable and rollbacks
> 
> 
> Yes -
> 
> I either need to modify all the objects or none of them. The 
> only way i can
> think of doing this at the moment is wrapping the objects in 
> a clonable
> wrapper and keeping a backup copy in case something goes wrong, or
> serializing a backup copy, any other ideas?
> 
> - Mark
> 
> 
> Mark Schreiber
> Bioinformatics
> AgResearch Invermay
> PO Box 50034
> Mosgiel
> New Zealand
> 
> PH: +64 3 489 9175
> 
>  
> 
> > -----Original Message-----
> > From: Matthew Pocock [mailto:mrp@sanger.ac.uk]
> > Sent: Tuesday, May 15, 2001 1:16 AM
> > To: Forsch, Dan
> > Cc: Schreiber, Mark; 'Biojava-L (E-mail)
> > Subject: Re: [Biojava-l] Changable and rollbacks
> > 
> > 
> > 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
> > >> 
> > 
> > 
> _______________________________________________
> Biojava-l mailing list  -  Biojava-l@biojava.org
> http://biojava.org/mailman/listinfo/biojava-l
>