incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <Janne.Jalka...@ecyrd.com>
Subject Workflow fail
Date Sun, 12 Apr 2009 09:52:59 GMT
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

Mime
View raw message