Sylvain Wallez wrote: > Jeremy Quinn wrote:
<snip/> >>> As the first implementation supports atomic updates, and some other are >>> likely do support it also, I was thinking of adding a rollback() method >>> on WriteableSource. But rollback is more related to the OutputStream or >>> ContentHandler than to the source itself. So what do you think ? >>> >> I think we still have the problem whereby Exceptions thrown by other >> parts >> of the pipeline can end up trashing the contents of the WritableSource, >> because the SourceWriter does not know this has happened. >> >> Is there any way rollback could be used under these circumstances? >> > After more thoughts, I will add the following methods to handle > abort/rollback on a WriteableSource : > > boolean canAbort(ContentHandler ch) > boolean canAbort(OutputStream os) > void abort(ContentHandler ch) > void abort(OutputStream os) > > This allows for transactional sources, such as the temp-file based > FileSource of an hypothetical SQLSource. The abort method doesn't > apply on the source only, but on the result of getContentHandler() or > getOutputStream(). Done, using the little time I have for Cocoon this week... The methods are called "cancel", which better means that all effects of a ContentHandler or an OutputStream are cancelled while "abort" may mean "keep what's been done up to now and leave it as is". Also, I didn't want to use "rollback" which is more SQL-oriented. Jeremy, could you please look at this for the SourceWritingTransformer ? I also added an "boolean exists()" on WriteableSource, which it could be well moved on Source. But is this change to the Source interface acceptable at this time, or should we wait for a 2.1 release ? Sylvain -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com http://www.apache.org/~sylvain --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
