> -----Original Message-----
> From: Robert Leftwich [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 30, 2002 4:13 AM
> To: [EMAIL PROTECTED]
> 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
> 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. "

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">
   <name>
   <street>
</read>

This is interpreted by the transformer into something like:
  object o = getBusinessObject("identifier for the object">
  o.getName();
  o.getStreet();
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>
</write>
etc.

Is this the way you mean?

Carsten

Carsten Ziegeler     Chief Architect     Open Source Group, S&N AG
------------------------------------------------------------------
             Cocoon Consulting, Training and Projects
------------------------------------------------------------------
mailto:[EMAIL PROTECTED]                  http://www.s-und-n.de
                    http://ziegeler.bei.t-online.de


> 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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to