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

The following comment has been added to this issue:

     Author: Hani Suleiman
    Created: Wed, 10 Sep 2003 8:20 PM
       Body:
This is a general problem with the JDBC store, which is why I'd recommend using ejb, hibernate, or ofbiz. Basically anything that supports tx, which the JDBC one does not currently. JTA could be used, except that if you have JTA, then chances are you're running in a decent server and could probably use a better store anyway!
---------------------------------------------------------------------
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