Does optimistic lock no longer work in KC ?

[Ronald Gouldner]

We have been finding strange issues with Awards and PD where changes people are making are not found when they later check the document.

In one production issue case we received an email notification regarding a changed attachment for an Enroute PD document.  However, when we looked at the document the original attachment was still present.  I checked the logs and found the user that changed the document had saved again 10 minutes after saving the document change.  This made me wonder if the second save was done from a second tab in the browser with the original unchanged document.  So I tested this and found this does in fact cause the new document to disappear and the original returns.

This happens in our version 1709.0022 of KC, I also tested on the Kuali resdemo current version and it too has the same issue.

The steps to reproduce are

Select a pd document with current attachments either in-progress or enroute.

1) In tab 1 - opened the pd doc

2) In tab 2 - opened same pd doc

3) Switched to Attachments tab in first copy (Tab1)

4) Switched to Attachments tab in second copy (Tab2)

5) Returned to tab 1 and replaced attachment file named xxxx.pdf with new attachment yyyy.pdf

6) open document in a new tab (Tab3) to confirm the file was in fact replaced. It should have file yyyy.pdf

7) Return to Tab 2 (notice it still has the old file listed xxxx.pdf since that is the file that was there when it was opened) - click save

8) you will now find when you open the document again it will have file xxxx.pdf and yyyyy.pdf is no longer attached.

This issue happens with in-progress and enroute documents.  So I tried a similar test with Award.

Open an in-progress Award Document in two tabs.  Change any data in one and save.  Save the other with no changes or different changes and note that the second save wins.

I clearly remember that this used to result in an Optimistic Lock Exception being thrown on the second save.  I remember chasing down how this was done in the past and the code in rice used ot check the loaded version of the data against the current version in the DB.  If the DB version was different then it meant the document was previously saved in another session and it refused the save throwing the Optimistic Lock Exception.

It is very common especially when our users are opening the document from an email notification that they might open the document twice.   Later when they find the second copy they feel it is safest to save in case they had made any changes.  Not realizing that this could in fact cause problems with previous saves.

I am not sure if this was changed in Rice base code or just in the special "KC Rice" version.   I have not yet chased down why this no longer works but having confirmed that it happens in the Kuali resdemo version also I am sure it wasn't caused by local config or changes.

Does anyone know why the optimistic lock was removed or no longer works?

Has anyone restored this functionality or found another way to prevent this issue?

[Ken Geis]

Hi Ron.

I just played your script on my KC 5.2.1 instance. It does the same. I'd bet this bug was always there.

I think this particularly affects narratives (i.e. PD attachments). They are separated into two entities/tables as an OJB workaround, and if you look at the code in NarrativeServiceImpl.replaceAttachment(..) and the method it calls Narrative.populateAttachment(), you'll see that a new NarrativeAttachment object is created when replacing the attachment contents. Because it's a new object, there is no optimistic locking conflict.

Ken

--
You received this message because you are subscribed to the Google Groups "KC Technical User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kc.technical.co...@kuali.org.

[Ronald Gouldner]

Ken,

Interesting.  Does your 5.2.1 instance allow you to make changes to other fields in this way without throwing the exception?

I can open a saved PD in two tabs and change any data in one and then overwrite the changes by saving the second.  This is true in Award also.

So Basically I can't make an optimistic lock exception happen no matter what I change.  I am sure at one time this exception prevented a user from saving in two different tabs/windows.  I am absolutely sure at one time optimistic locking worked.  Our KFS lead has confirmed that attempting such a change on a KFS document does in fact fail for the second save attempt with an optimistic lock.  So at some point the KC version of Rice must have made a change causing this bug.

With enroute changes matters get worse because there is no pessimistic lock applied enroute.  Rice thinks the document is enroute so doesn't apply a pessimistic lock since the document should be in view only mode.  Since KC allows various changes while enroute you can perform the same experiment as two entirely different users.  So if two people have the document open at one time and one makes changes while the second user also makes changes the second save will win overwriting the first.

Ron

Hi Ron.

To unsubscribe from this group and stop receiving emails from it, send an email to kc.technical.collab+unsub...@kuali.org.

[Ken Geis]

Yes, I assumed it was because of the special modeling of attachments, but I just tried with sponsor proposal number, and it shows the same behavior.

By the way, I don't have access to kr_on_p...@kuali.co. Feel free to forward my responses there.

Ken

[Ronald Gouldner]

Thanks for the extra testing Ken.  Interesting this was broken in 5.2.1 as well.  I guess this was broken longer than we realized.   I will have to dig into this deeper and figure out what happened.  I appreciate the feedback. 

Ron

Hi Ron.

To unsubscribe from this group and stop receiving emails from it, send an email to kc.technical.collab+unsubscribe...@kuali.org.