-
I have an issue with locking on the web. I have it pretty much working seamlessly, so it’s like the automagic locking in the Notes client. But I have one timing issue remaining … when an error occurs and the page reloads (because of the error) instead of transitioning, the code to make sure a lock exists pretty consistently runs before the code to unlock, so I wind up with an unlocked document in edit mode.
-
This happens because lock is done in postOpenDocument (on the server) and unlock is done in window.onunload (in the client) using an AJAX call. I used that for unlock because I could find no event on any XPage that I could guarantee would run, even if the user closed the browser. Only window.onunload does the trick.
-
One would think a page reload would do onunload first and then pOD, but since it’s two separate systems there’s no real reason it should, and it doesn’t. Normally pOD runs, then onunload runs.
-
Code runs in postSaveDocument, a complex batch of legacy stuff in an Agent. I run it there because I’m afraid if I wrap it in AJAX and run it willy-nilly there will be a conflict with the in-memory document the XPage itself is using, because this code can conceivably change any field on the document. In pSD the XSP processor seems to deal nicely with ad-hoc changes, so I’ve left that legacy code there. But it doesn’t have to stay there. One solution could be to wrap the legacy code in AJAX and run it from the client, then I won’t have to do a page reload for an error condition, and reload timing becomes moot.
-
What I’ve done is set a scoped variable to indicate a reload is happening and attempted to introduce a fixed delay, but while the server runs that code, it doesn’t actually delay anything. That’s a kludge, but if it works I’ll go with it while I figure out something better.
-
I could also do an AJAX lock on window.onload. I’ve kept pOD because that’s where I started doing it, and it works, so I’ve left it there.
Any thoughts? Thanks for your time…