Questions & Answers

[king]

Dear FirstSpirit Community,

we just wonder whether there is a difference between the following StoreElement lock-API calls:

setLock(true);
setWriteLock(true);

Our questions:

• do both calls handle different scenarios?
• is it possible to set both locks in parallel?

[marro]

Hello,

with setWriteLock(true) you change the value of a simple flag that indicates whether this StoreElement can be written or rather should not be altered (e.g. if the StoreElement is used in a workflow and you don't want it to be changed during execution of this workflow, you could set this flag so that other scripts would be able to check if it's safe to apply changes to this StoreElement).

To apply changes to a StoreElement it is necessary to lock the StoreElement by calling setLock(true) first.

So it's possible to set both locks in parallel, but since locking a StoreElement with setLock(true) prevents other users from editing the same StoreElement, it's not necessary to set the writeLock additionally.

[king]

Dear Mr Donato,

we currently observe, that within the BeanShell-Console:

• when we set "setWriteLock(true)" on this element (here: in FirstSpirit SuperAdmin mode)
• the element could still be "check out" within the FirstSpirit JavaClient without any graphical exception

Our expectation was: an exception coming up

[StefanSchulz]

Hi,

Holger King schrieb:

we currently observe, that within the BeanShell-Console:

• when we set "setWriteLock(true)" on this element (here: in FirstSpirit SuperAdmin mode)
• the element could still be "check out" within the FirstSpirit JavaClient without any graphical exception

Our expectation was: an exception coming up

Not sure, where you draw this expectation from, but there will be no Exception be thrown for using the write lock indicator. As Donato said, the write lock flag is intended to indicate not to apply changes on this object. It does not lock the element for changing it.

As the API documentation notes, it is used, e.g., when an element is in some workflow state, where no concurrent changes should be made until the workflow proceeds to a different state.

Cheers,

Stefan

[AuM]

Hi,

thanks for the explanation but there is something i am wondering about.

If a workflow state causes the writelock (due to the writelock-checkbox is checked), then e.getWriteLock() returns true and it is not possible to check out this element (a WorkflowLockException is thrown) until:

• the workflow continues to a non-writelocked state or
• setWriteLock(false) is called on the element

If the writelock is set via API without any workflow the e.getWriteLock also returns true but it's still possible to check out the element and edit it.

From my (external) point of view both functionalities (workflow, API) do use the same methods (get/setWriteLock()) but act differently, why is this so?

And even more important: is there any possibility to emulate the workflow-state behavior (to make shure nobody changes the element)?

Cheers,

Martin

[gockel]

Hi Martin,

did you save your changes (#setWriteLock(true)) on the element?

myElement;
boolean wasLocked = myElement.isLocked();
try {
     if ( ! wasLocked) {
          myElement.setLock(true, false); // lock non-recursive 
     }
     myElement.setWriteLock(true);
     myElement.save("setting write lock", false);     // save non-recursive
} catch(LockException lockFailed) {
     context.logError("lock failed -> medium already locked by " + lockFailed.getUserLoginName());
} finally {
     try {
          if ( ! wasLocked) {
               myElement.setLock(false, false);     // unlock non-recursive
          }
     } catch(Exception unlockFailed){
          // todo proper error handling
     }
}

After executing these lines the element "myElement" shouldn't be editable anymore.

[AuM]

Hi Sebastian,

well i didn't save the writelock, probably forgot it...

Thanks a lot, with saving the writelock we get the expected results (Exception via API and Pop-up via JavaClient) !

But the i'm a little confused about the statement of Mr. Schulz:

Stefan Schulz schrieb:

As Donato said, the write lock flag is intended to indicate not to apply changes on this object. It does not lock the element for changing it.

With saving the WriteLock it worked as we expected, so the element is not editable for anyone until the WriteLock is removed. Why did you say it doesn't lock the element for changing it? Is there something we did not consider?

Yours,

Martin

[StefanSchulz]

There seems a bit of confusion with respect to the word "lock". The setLock-method locks the element (so you are the only one who can alter its data). The setWriteLock-method does not lock the element for alteration but it actually sets some flag (meta data) which gets evaluated when trying to modify the element (causing to refuse alterations).

Hm, not sure, this explanation makes it really clear :smileyblush:

Cheers,

Stefan