Two users are able to open a node for editing at same time when they go directly to the edit page without viewing the node.

Both get the message "This document is now locked against simultaneous editing. It will unlock when you navigate elsewhere."

When the first one to edit the node tries to save edits, this message is given:

"Your lock has been removed!
This document is locked for editing by aaron since Wed, 01/07/2009 - 17:44.
You can still save the content if this user aborts the edit operation without saving changes."

I will try to look into this when I have time.

Comments

B00N’s picture

Priority: Normal » Critical

Hi,

I got a similar problem. If User A starts editing the node, the message is: "This document is now locked against simultaneous editing. It will unlock when you navigate elsewhere.".

But when User B also edit the node, he/she gets the same message.

What happend?

Action User A: INSERT nid, uid, timestamp in {checkout} table. But it seems it's gonna deleted immediately after inserting.
Action User B: There's no entry in {checkout}, so INSERT nid, uid, timestamp in {checkout} ... AND .... DELETE. Entry is gone.

When I turn of Javascript, it works - Node ist locked for other users - but after editing, it won't release the lock.

I tried to find the bug, .....

greylogic’s picture

Possible race condition in checkout process:

I was going through the checkout modules code to get some ideas for my custom module (which needs a similar functionality at a node field level). It seems there is a race condition in the code which will allow more than one user to think they got a lock on a node for editing.

function checkout_node($nid, $uid) {
  if ($lock = checkout_fetch_lock($nid)) {
    ....
  }
  else {
    // Lock node.
    db_query("INSERT INTO {checkout} (nid, uid, timestamp) VALUES (%d, %d, %d)", $nid, $uid, time());
  }

  return TRUE;
}

If two threads happen to run the checkout_fetch_lock() at the same time on a unlocked node, both the threads will get False $lock objects. Both the threads now try to insert the row into {checkout} table. That's fine since only one will be successful. However the function returns TRUE to both the threads. This causes both the threads to think they have the lock. The function should return the return value of db_query() instead of returning TRUE all the times. This will make only one of the threads to get the lock.

Also the function call

drupal_set_message(t('This document is now locked against simultaneous editing. It will unlock when you navigate elsewhere.'));

should be run only if the return value of the insert is TRUE.

B00N’s picture

Hello,

some news from me. After hours of testing and trying, i found a solution for one of my sites. I use the FCKEditor Module. If i disable the FCKEditor for the users in editor-role, checkout works.

As i mentioned, this works for one of my sites. On an other site is still have the problem that i subscribed in post #1. Only switching off javascript in the browser settings, helps here.

Anyone some new tipps or hints?

Bye Franzer

B00N’s picture

Hey,

i opend a new issue: http://drupal.org/node/386666

Franzer

Frank Steiner’s picture

Check http://drupal.org/node/281584
Things can be fixed if ajax requests are marked as such.

smk-ka’s picture

Status: Active » Fixed

@awolfey
I think this has been fixed in CVS, so updating to the latest development snapshot should help. Feel free to reopen if the problem persists.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.