Process Mapping Logo

Process Mapping - Forums

Sharing 19 years of knowledge and experience

 
Metastorm BPM forums
Sign up Latest Topics
 
 
 


Reply
  Author   Comment  
FatPeer

New Member
Registered:
Posts: 5
Reply with quote  #1 
Hi,

User encountered an error as " Folder not locked for action. Failed to commit action". When i checked the eventviewer there are several messages like " <ActionName>  by  <Username>  was denied, the user does not hold a lock on folder  <folderid>  and there is no errors in the elog table.

I have checked some other posts and they mentioned like 2 users accessed the same folder. But in my case 2 users are not accessed the same folder. Kindly help with this.


__________________
FathiPeer
0
PresuminEd

Avatar / Picture

Member
Registered:
Posts: 25
Reply with quote  #2 

What the system is telling you is that by the time the user comes to attempting to commit an action, that user no longer has a lock on the folder.

 

An obvious cause would be that the folder lock timeout has elapsed.   Assuming the default folder lock timeout of 60 mins:

 

1. UserA starts an action the folder at 10:00.   So there is a lock on the folder for UserA, showing that it was locked at that time.

 

2. UserA is taking his time...and an hour has passed.

 

3. UserB tries to start an action against that folder - and succeeds (because UserA's folder lock has expired.

 

4. UserA finally comes to committing the action...and is shocked by the error message.

 

Cheers,

Ed.


__________________
Any comments I make are mine alone, and do not necessarily reflect the views of my employer...May contain nuts...Open other side up...Contents may have settled during transportation...
0
FatPeer

New Member
Registered:
Posts: 5
Reply with quote  #3 
Many thanks for the reply Ed. Kindly let me know how to rectify this issue. Because I'm in the learning phase and it is a production issue. Please help.

__________________
FathiPeer
0
PresuminEd

Avatar / Picture

Member
Registered:
Posts: 25
Reply with quote  #4 

The first thing I would do is try to confirm whether the scenario I described above is actually what is happening;  or whether this explanation does not fit the known facts.

 

To do that I would check the eEvent table to see the audit trail for the particular folder of interest.   Do you see an action being performed against the folder at a time which might be consistent with what UserA reports?

 

Be aware that the scenario I describe may not play out exactly as expected or as I describe.   For example:

 

- After step 4, UserB may actually have cancelled his action.   Meaning that nothing about this action appears in the eEvent table.
- UserB may not be a human user at all; but rather the engine's event manager performing a system action (e.g. timer or flag).   Again, this attempted action may or may not have succeeded.

 

Cheers,

Ed.

 


__________________
Any comments I make are mine alone, and do not necessarily reflect the views of my employer...May contain nuts...Open other side up...Contents may have settled during transportation...
0
BMellert

Guru
Registered:
Posts: 688
Reply with quote  #5 
Also, of the 1-4 scenario listed below, the same error will occur if user A open the folder in edit mode but doesn't do anything for an hour (again, presuming the 60 minute default) then tries to save.  Another user/action (step 3) doesn't have to occur.

The best thing to advise users is to finish their task within the time out.  This can be a save and reopen if needed.

The lock timeout can be extended, but 60 minutes should be well over what any user should need to do something in edit mode.

- See correction below -
0
PresuminEd

Avatar / Picture

Member
Registered:
Posts: 25
Reply with quote  #6 

Quote:
Also, of the 1-4 scenario listed below, the same error will occur if user A open
the folder in edit mode but doesn't do anything for an hour (again, presuming
the 60 minute default) then tries to save.  Another user/action (step 3) doesn't
have to occur.

 

Errr...no!

 

If that's the behaviour you're seeing that's a problem - and I really want to know about it.   But I just checked (by setting the timeout to 2 mins), and it works as I described.   Have a go yourself.

 

The engine doesn't have an 'active' mechanism for unlocking expired folder locks.     So if we omit step 3 from the sequence below, step 4 should work, even if the user waits till the end of the day to commit.   Or the end of the week....or the month...

 

Cheers,

Ed.

 


__________________
Any comments I make are mine alone, and do not necessarily reflect the views of my employer...May contain nuts...Open other side up...Contents may have settled during transportation...
0
FatPeer

New Member
Registered:
Posts: 5
Reply with quote  #7 
Hi Ed,

I'm able to replicate the issue. When User A locks the folder for sometimes and left as such. and User B(opened the same folder for same action with same username) tries to access the same page and it is successful for User B. When User A commits the same action it results that error. And in eevent table the entries are related to Flag/system action.

Thanks


__________________
FathiPeer
0
PresuminEd

Avatar / Picture

Member
Registered:
Posts: 25
Reply with quote  #8 

Assuming that you are using the default folder lock timeout of 60 minutes, then I suspect you probably need to alter user behaviour and/or alter your solution.

 

Folder locks are useful for helping to divide up work amongst users dynamically, but there's a timeout for a reason.  A folder locked to a user means that work on that folder cannot be done by any other user - including the pseudo-user responsible for carrying out system actions.   Normally the desirable behavour of a system is to allow as much throughput as possible;  but folder locks effectively act as bottlenecks to achieving such throughput.

 

It is for this reason that folder lock timeouts are seen as desirable.    It is possible to remove folder lock timeouts altogether (by setting it to zero); or by lengthening the timeout;  but this requires serious thought since the side-effects of going this way may well be even less desirable than the current situation you are trying to remedy.

 

For the situation you describe to occur requires that users are starting actions, and then failing to commit (or cancel) these actions in a timely fashion.   Really you want to stop this situation occurring - or at least make it a rare occurence.

 

You could address this by educating users to reduce the time they take to perform an action.

 

Or in fact the reason for this behaviour may have another cause - for example, huge forms which take too long to fill in.

 

In this instance it makes sense to look at ways to break up such interactions into bite-sized and easily-completed pieces.    Meaning that any one action can be performed in a relatively quick time.

 

Building on this, you could break this series of steps into a number of loopback actions at a stage, with the folder only moving to the next stage when that work is deemed complete.

 

But it may be that you do have a requirement to ensure that an action needs to performed by one user - and one user only - at a time, possibly over some duration of time.   In this case you could look at having a "pick up" action which moves the folder to a separate stage, and which only allows the nominated user with this folder on the ToDo list to perform any actions on it.

 

In that instance, you would need to ensure that no system actions could intrude.   So maybe that requires a separate (but associated) map/process to manage this.

 

These are just a few ideas off the top of my head.

Cheers,

 

Ed.

 


__________________
Any comments I make are mine alone, and do not necessarily reflect the views of my employer...May contain nuts...Open other side up...Contents may have settled during transportation...
0
BMellert

Guru
Registered:
Posts: 688
Reply with quote  #9 
I stand corrected - and see it works differently that I thought and was led to believe.

I put a folder in edit mode and left it alone for 78 minutes.  (Our lock time-out is the standard 60 minutes.)  Nothing else was done on the folder and I was able to successfully save and the changes took.
0
PresuminEd

Avatar / Picture

Member
Registered:
Posts: 25
Reply with quote  #10 

In fact it looks as though Jerome pre-empted the need for any description from me:

 

http://metastorm.processmapping.com.au/post/Folder-Locks-and-Timeouts-3230690

 


__________________
Any comments I make are mine alone, and do not necessarily reflect the views of my employer...May contain nuts...Open other side up...Contents may have settled during transportation...
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:


Create your own forum with Website Toolbox!