incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <>
Subject Re: Workflow fail
Date Sun, 12 Apr 2009 21:56:28 GMT
This makes sense. Using the repository foe storing workflows is a very  
good idea. In general, all workflows should be stored in the repo...  
so that they are always persisted.

We should also take a look at the two workflows we have now (page  
saves and profile creation). Today, we create a workflow for every  
page save and every profile creation. Even those that don't need  
approvals have a "straight-through" (i.e., no decision) workflow. This  
was easy to code, but pretty wasteful. For those no-decision cases,  
just saving the page or creating the profile, without setting up a  
workflow, would be better.


On Apr 12, 2009, at 5:52, Janne Jalkanen <>  

> Heya!
> I just realized something - the way that workflows currently work  
> does not scale. The problem is that preSaveTask stashes all of the  
> attributes of the page into memory (and assumes it can serialize it).
> Now, in 3.0 the attribute map cannot exist, since e.g. page content  
> will be an attribute. This means that attributes can span gigabytes  
> (like with attachments), and you probably don't want those in memory.
> Another problem is that copying all of the attributes and restoring  
> them will probably cause all the attributes to be versioned again  
> since we overwrite all attributes with the ones from memory.  That  
> is, every single versioning will create complete copies of all  
> attributes since we rewrite all of them each time...  Though this  
> could very well be something that the repository does anyway, but at  
> least we're not helping it.
> This means that the whole workflow storage will need to be rethought  
> a bit.  My current idea is that we just simply add a new Node in the  
> repository:
> /wiki:workflows/
> and we add the workflow information into that repo as a series of  
> Nodes. For example:
> /wiki:workflows/<workflow-id>/<node-uuid>/<modified attributes>
> This allows a couple of things to happen:
> 1) workflows are clustered automatically
> 2) we don't need serialization anymore, since we just copy JCR  
> Properties back-n-forth
> 3) workflows are persisted automatically
> 4) workflows could in the future contain multiple objects
> 5) workflows can be exported and backed up together with the repo  
> contents
> How does this sound?  We do also want to create a canonical  
> representation of a workflow object, and this might need a bit of  
> design.  I'm not *that* familiar with the way it works, so some help  
> might be needed here.
> /Janne

View raw message