Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-Id: <5.1.0.14.0.20020830114757.01c02e50@192.168.0.5>
Date: Fri, 30 Aug 2002 12:12:47 +1000
To: cocoon-dev@xml.apache.org
From: Robert Leftwich <robert@leftwich.info>
Subject: Novel persistence approach and Cocoon
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit

I recently came across a new approach to persistence called object 
prevalence {1}, implemented in the open source Prevayler project [2]. It is 
basically a journalling object system in the same vein as a ReiserFS, etc

 From [1]:
"In a prevalent system, everything is kept in RAM, as though you were just 
using a programming language. Serializable command objects manage all the 
necessary changes required for persistence. Queries are run against pure 
Java language objects, giving developers all the flexibility of the 
Collections API and other APIs, such as the Jakarta Commons Collections and 
Jutil.org. Before changes are applied to business objects, each command is 
serialized and written to a log file. Then, each command is executed 
immediately. Optionally, in a low-use period, the system can take a 
snapshot of the business objects, aggregating all the commands applied into 
one large file to save some reloading time.
During system recovery after a shutdown or system crash, the system 
retrieves its last saved state from the snapshot file (if one is available) 
and then reads the commands from the log files created since the snapshot 
was taken. These commands are applied to the business objects exactly as if 
they had just come from the system's clients, including the system clock. 
Thus, the system returns to the state it was in just before the shutdown 
and is ready to run.
For a prevalent system to work correctly, its business objects must follow 
two very simple rules. The business objects must be:
�	Serializable - At any point in time, the system might want to persist an 
object to disk or other non-volatile media.
�	Deterministic - Given some input, the business object's methods must 
always return the same output. "

Now, I was thinking of using it in Cocoon and instead of being business 
object focused it would be XML-focused or perhaps more accurately 
DOM-focused, in that it would be persisting DOM's rather than business 
objects. My initial thoughts are to implement a variation of the 
SourceWritingTransformer using Prevayler instead of the file system as the 
persistence mechanism by coding the insertFragment() function as a Command 
object (or better still 2 Command objects - insert and replace).

My knowledge of the internals of Cocoon at this point in time is minimal, 
so I would appreciate some feedback on whether this is the right place to 
start experimenting with a Cocoon/Prevayler read/write tie in. All comments 
gratefully accepted!

I'd encourage everyone to read these links as it appears to be a very 
exciting development in making persistence a transparent, simple, yet 
extremely fast and robust process.

Robert


[1]  http://www-106.ibm.com/developerworks/web/library/wa-objprev/index.html
[2] http://www.prevayler.org/wiki.jsp?topic=StartingPoints


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org