cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: Novel persistence approach and Cocoon
Date Fri, 30 Aug 2002 12:44:49 GMT

> -----Original Message-----
> From: Robert Leftwich []
> Sent: Friday, August 30, 2002 4:13 AM
> To:
> Subject: Novel persistence approach and Cocoon
> 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
> 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. "

Sounds interesting!

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

I don't understand exactly what you mean - you could (easily) write
a transformer interacting with business objects managed by a
a prevalent system. For example for reading
<read businessObject="identifer for the object">

This is interpreted by the transformer into something like:
  object o = getBusinessObject("identifier for the object">
And the results are inserted into the SAX stream.

And the way back could look like this:
<write businessObject="identifer for the object">
   <name>some name</name>
   <street>and a street</street>

Is this the way you mean?


Carsten Ziegeler     Chief Architect     Open Source Group, S&N AG
             Cocoon Consulting, Training and Projects

> 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]
> [2]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message