Coming to SuperNTF - Document Locking That Rocks
Category SuperNTF OpenNTF Lotus Notes
Hello Everyone, remember me? Great,
thanks for your patience. I will now begin to reward it.
You'll be happy to know that I've been busy cooking up batches and batches of cool stuff, ranging from (hopefully) entertaining and informative session slides to slick (and useful!) new SuperNTF features. The long rainy weekend passed with little human contact ("Yes Honey, I promise to eat vegetables while you and Junior spend 2 months visiting your family."), and the basic rhythm went something like this:
As the title of this post suggests, the primary focus of this intensely focused coding binge was document locking. As you are all no doubt aware, document locking has been a native feature of Notes since version 6. Unfortunately, utilizing this cool new functionality, which previously required all kinds of coding heroics to achieve, isn't as simple as turning it on and living happily ever after.
Once you get past the basics, there are a number of implementation best practices necessary to override some default behavior that can result in bad things happening (e.g. data loss). Without getting into too much detail, one of the techniques I've adopted is to explicitly lock a document (with a "persistent lock") before it is placed in edit mode, which allows me to prevent Notes from issuing a "provisional" lock if the master lock server (i.e. the Admin server) is unavailable. Provisional locks occur in cases when documents in offline local replicas (or any "disconnected" replica for that matter) are edited. They are bad because those changes might be lost completely if another person edits the same document in between replications. The worst that can happen when using this technique is that a replication/save conflict is created, which can always be manually reconciled (I highly recommend Ytria ScanEZ for conflict resolution).
Another key problem with document locking that isn't addressed adequately is "forgotten" locked documents. This can happen when a user manually locks a document and neglects to unlock it later, or their Notes client crashes while editing a document. I've approached this problem in two ways. The first is to create a view showing all locked documents and by whom and when they were locked. This view contains an action allowing administrators to manually remove the locks.
The second approach is to implement a scheduled agent that checks for locked documents that have been "abandoned" for longer than some configurable amount of time, and then removes the locks and notifies the lock holder it has done so.
For user convenience I've also added elements to forms that display a document's current lock status, and all views contain an icon column that shows a lock next to any locked documents.
To build all this I was helped tremendously by a great VIEW article and accompanying database by James Ray, as well as a great bit of code written by Chad Schelfhout. Definitely worth checking out both, although the best bits from both these sources have been distilled for ease of use in the upcoming SuperNTF release, so you may want to hold off playing for another couple weeks (I hope
).
Stay tuned for more...
Hello Everyone, remember me? Great,
thanks for your patience. I will now begin to reward it.
You'll be happy to know that I've been busy cooking up batches and batches of cool stuff, ranging from (hopefully) entertaining and informative session slides to slick (and useful!) new SuperNTF features. The long rainy weekend passed with little human contact ("Yes Honey, I promise to eat vegetables while you and Junior spend 2 months visiting your family."), and the basic rhythm went something like this:
Sub Initialize
CONST CAFIENNATED_BEVERAGE = "Tea"
Forall days in Weekend
code
feed cats
eat(True) 'optional parameter indicates whether coding occurring simultaneously
code
HDTVbreak("Discovery Channel", True) 'True indicates, you guessed it, coding
Drink(CAFIENNATED_BEVERAGE)
feed cats
code
eat(True)
code
HDTVbreak("Saturday Night Live", True)
sleep(True) 'optional parameter indicates whether dreaming in code
wake
Drink(CAFIENNATED_BEVERAGE)
End Forall
End Sub
As the title of this post suggests, the primary focus of this intensely focused coding binge was document locking. As you are all no doubt aware, document locking has been a native feature of Notes since version 6. Unfortunately, utilizing this cool new functionality, which previously required all kinds of coding heroics to achieve, isn't as simple as turning it on and living happily ever after.
Once you get past the basics, there are a number of implementation best practices necessary to override some default behavior that can result in bad things happening (e.g. data loss). Without getting into too much detail, one of the techniques I've adopted is to explicitly lock a document (with a "persistent lock") before it is placed in edit mode, which allows me to prevent Notes from issuing a "provisional" lock if the master lock server (i.e. the Admin server) is unavailable. Provisional locks occur in cases when documents in offline local replicas (or any "disconnected" replica for that matter) are edited. They are bad because those changes might be lost completely if another person edits the same document in between replications. The worst that can happen when using this technique is that a replication/save conflict is created, which can always be manually reconciled (I highly recommend Ytria ScanEZ for conflict resolution).
Another key problem with document locking that isn't addressed adequately is "forgotten" locked documents. This can happen when a user manually locks a document and neglects to unlock it later, or their Notes client crashes while editing a document. I've approached this problem in two ways. The first is to create a view showing all locked documents and by whom and when they were locked. This view contains an action allowing administrators to manually remove the locks.
The second approach is to implement a scheduled agent that checks for locked documents that have been "abandoned" for longer than some configurable amount of time, and then removes the locks and notifies the lock holder it has done so.
For user convenience I've also added elements to forms that display a document's current lock status, and all views contain an icon column that shows a lock next to any locked documents.
To build all this I was helped tremendously by a great VIEW article and accompanying database by James Ray, as well as a great bit of code written by Chad Schelfhout. Definitely worth checking out both, although the best bits from both these sources have been distilled for ease of use in the upcoming SuperNTF release, so you may want to hold off playing for another couple weeks (I hope
).
Stay tuned for more...
- 
Full Posts
Comments
Comments
Hope all is well!
I'm having issues with a 6.5 version of doc locking. I opened a support ticket with Lotus Support. They provided a fix that we applied to our test server and we will be applying to prod soon. We have an application that has a couple docs a day that won't willingly give up the lock. Difficult to troubleshoot as I don't know what the user could possibly be doing that would cause this. I don't think they're savvy enough to be locking these docs manually and forgetting. I like your thoughts/code on running an agent to unlock especially if this fix does not do the trick. Can you share this code? Thanks!
Posted by Curt Stone At 01:36:46 PM On 04/09/2008 | - Website - |
The problem I'm trying to handle now was reported by another SuperNTF user, and relates to what is essentially a Notes bug when using document locking in combination with soft deletions: { Link }
I can reproduce this problem pretty easily but I still haven't perfected a fix that will allow for the soft deleted documents to be restored AND unlocked at the same time. I can certainly lock before deleting, but after that things are still messy. If anyone has thoughts on how to LOCK - SOFT DELETE - UNLOCK so that documents in the Trash are unlocked, please share.
As mentioned above, I'm currently working on the approach of leaving the documents locked in the trash, and unlocking them during the restore process. I've had some success with this but so far the documents seem to come back slightly corrupted, thinking they are still deleted but showing up normally.
Posted by Kevin Pettitt At 03:08:03 PM On 04/09/2008 | - Website - |
I still have some cleanup in terms of exception handling, as well as more testing to confirm that users with lower access levels but the right roles will have the desired capabilities. I may even try to remove the locks via brute force at deletion time instead of on restore. We'll see.
Posted by Kevin Pettitt At 04:47:01 PM On 04/09/2008 | - Website - |
Posted by Chad Schelfhout At 06:27:41 AM On 04/11/2008 | - Website - |
Actually you can help. While I've used your class for the basics of locking and unlocking, I'm not sure I'm doing using it to its full potential. I also think there are probably other uses that I'm overlooking. What's missing from your download are usage examples for each of the various class features. Can you post an example db to show how the pieces all fit together?
Thanks
Posted by Kevin Pettitt At 07:15:36 AM On 04/11/2008 | - Website - |