incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <andrew.r.jaqu...@gmail.com>
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.

Andrew

On Apr 12, 2009, at 5:52, Janne Jalkanen <Janne.Jalkanen@ecyrd.com>  
wrote:

> 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