[JIRA-OS] Commented: (WF-144) Non atomicity of step transition

The following comment has been added to this issue:

     Author: Thomas Morin
    Created: Thu, 11 Sep 2003 2:26 AM
       Body:
Well, I'd "say and no", for three reasons :
- one might like to have a non-corruptible backend without heavyweight infrastructures (EJB, JTA...)
- with an adapted SQL structure, you can easily have enough atomicity as to avoid data model inconsistency. As far as I can tell, the major drawback of the current JDBC store implementation is that there are 2 tables for storing step informations (current and history), and the major problem I have seen happening is the non-atomic move of a step between those two tables. With only one table, and a column indicating if this is history or not, we wouldn't have this problem (atomic SQL "UPDATE", etc.).

So, I would say it might be nice to have a different implementation of the JDBC store, using only one table for step information : this would give enough atomicity to the backend as not to corrupt the data model.

---------------------------------------------------------------------
View the issue:

  http://jira.opensymphony.com/secure/ViewIssue.jspa?key=WF-144


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: WF-144
    Summary: Non atomicity of step transition
       Type: Bug

     Status: Assigned
   Priority: Major

    Project: OSWorkflow
 Components: 
             Core
   Versions:
             2.1

   Assignee: Patrick Lightbody
   Reporter: Thomas Morin

    Created: Tue, 25 Mar 2003 9:28 AM
    Updated: Tue, 25 Mar 2003 9:28 AM
Environment: OSWorkflow used by web application.
JDBCWorkflowStore/MySQL.

Description:
I have an application with a simple workflow that does no split.
However, my users found a way to have a workflow entry end up in a state where it has more than one current step.

Here is the situation where it happens :
 - the user is on a page presenting him with the different actions he can do on an entry
 - he makes an action (validate a form)
 - for whatever reason, not long after, he make the action a second time
  (feeling slowly, hand shaking, you imagine the thing)
 - depending on the timing, the task sometimes end in a state where it has two current steps

Since this can even be two different steps, this may be very disturbing for users.

My understanding is that the JDBCWorkflowStore is changing/copying/moving step information in a way that is not atomic.

Perhaps there should be a lock associated to eash entry, preventing this  kind of atomicity probleme to happen? 
Perhaps this lock should be implemented at the AbstractWorkflow level, which would be profitable to all type of stores ? (reason why component of this issue is Core)

Well, perhaps I'm just misleading.. ?




---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.opensymphony.com/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf