gghaleb
asked on
Locking and Concurrency in Lotus notes appliocations?
Hi,
I am currently learning how to make applications on the Domino Designer, However, before I continue learning...I want to ask if something is possible in lotus notes applications or not.
I would like to create an application to store documents, or text items, however, this system is to be used by many people at the same time, however, there is always the problem of people overwritting other peoples documents or text items.
Is it possible to implement locking in Lotus Notes? i.e. do not allow more that one person to edit the same document at the same time?
I am currently learning how to make applications on the Domino Designer, However, before I continue learning...I want to ask if something is possible in lotus notes applications or not.
I would like to create an application to store documents, or text items, however, this system is to be used by many people at the same time, however, there is always the problem of people overwritting other peoples documents or text items.
Is it possible to implement locking in Lotus Notes? i.e. do not allow more that one person to edit the same document at the same time?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi Marko,
Is it possible to allow this to be done automatically in Lotus Notes, with out the user having to lock it?
i.e. as soon as the user clicks on "Edit Document" button, it is automatically locked?
Is it possible to allow this to be done automatically in Lotus Notes, with out the user having to lock it?
i.e. as soon as the user clicks on "Edit Document" button, it is automatically locked?
Hi gghaleb,
Yes, you'd have to code it to do this, again, as mbonaci suggests, open designer help to LOCK document, and read Lock Document method for Lotus Script, etc.
Regards!
Yes, you'd have to code it to do this, again, as mbonaci suggests, open designer help to LOCK document, and read Lock Document method for Lotus Script, etc.
Regards!
I'd say that, when several people could be updating the same document at the same time, there is an organizational problem.
Locking COULD be a solution, but ONLY when you have some sort of transaction that requires locking. IMHO, locking should never be used just to prevent replication or save conflicts to happen. In Notes, there's always the possibility to Merge replication conflicts (when different fields are updated, the latest updates will appear in the merged document). There are good tools available to handle conflict documents, e.g. Difference of two documents, from the Sandbox. See
http://www-10.lotus.com/ldd/sandbox.nsf/ByAudience/17c785f8028e7c8785256a7000497fd9?OpenDocument
Don't make things more difficult than need be.
Locking COULD be a solution, but ONLY when you have some sort of transaction that requires locking. IMHO, locking should never be used just to prevent replication or save conflicts to happen. In Notes, there's always the possibility to Merge replication conflicts (when different fields are updated, the latest updates will appear in the merged document). There are good tools available to handle conflict documents, e.g. Difference of two documents, from the Sandbox. See
http://www-10.lotus.com/ldd/sandbox.nsf/ByAudience/17c785f8028e7c8785256a7000497fd9?OpenDocument
Don't make things more difficult than need be.
Agreed... but had one employee service request application that followed a particular workflow-- that is, somone requested a,b,c,d,e - and a,b,c were handled by one person, d and e by different people. The workflow was such that anyone could mark the task complete at any time, but in cases where people left the company, we'd have five or six different people opening the same form to mark a task complete across replicas... many replication conflicts without locking. This was 5.12, so you can imagine without ocking the workaround I had to code to prevent someone from editing a document when someone else had it open.
This is not an organizational problem, but a fairly typical workflow when several departments have to act on some task and all may do it at the same time.
If that is the case here, then the criticism is unjustified, perhaps.
Also, the difference between two docs is fine when you have one conflict that you need to resolve. I ended up writing a dandy merge two conflicts, including rich text fields... :)
This is not an organizational problem, but a fairly typical workflow when several departments have to act on some task and all may do it at the same time.
If that is the case here, then the criticism is unjustified, perhaps.
Also, the difference between two docs is fine when you have one conflict that you need to resolve. I ended up writing a dandy merge two conflicts, including rich text fields... :)
marilyng,
> The workflow was such that anyone could mark the task complete at any time...
and
> This is not an organizational problem, but a fairly typical workflow when several departments have to act on some task and all may do it at the same time.
Now where's the "flow" here?? Wouldn't you say that it's not work-flow, but more like work-pool? Or work-puddle? ;)
> The workflow was such that anyone could mark the task complete at any time...
and
> This is not an organizational problem, but a fairly typical workflow when several departments have to act on some task and all may do it at the same time.
Now where's the "flow" here?? Wouldn't you say that it's not work-flow, but more like work-pool? Or work-puddle? ;)
The work flow is that they all have to mark it complete, but there isn't any requirement that A must happen before B. That is I can create a Notes user before I have the hardware in place to install a notes client. When all tasks are complete then it moves to the next level.
I also have seen those really simple applications where person A opens a document to add to discussion item, and then goes off to a two hour meeting - leaving the document in edit mode. Meanwhile, person B opens another instance and adds to the same discussion item, closes and save it. Person A comes back, dots the i's, saves and closes their document and creates a conflict. Person A's doc is the one saved, and Person B's doc is the conflict.
The point is not what you want to call a work-flow, but when you want/need to engage locking. Obviously and since Lotus added the functionality, it was something a great number of people requested.
Maybe you'd like some beads to go with that work-puddle diversion dance? (**sound of drums and chanting**room filling with smoke**omygosh! I can't see the question anymore!!!***)
I also have seen those really simple applications where person A opens a document to add to discussion item, and then goes off to a two hour meeting - leaving the document in edit mode. Meanwhile, person B opens another instance and adds to the same discussion item, closes and save it. Person A comes back, dots the i's, saves and closes their document and creates a conflict. Person A's doc is the one saved, and Person B's doc is the conflict.
The point is not what you want to call a work-flow, but when you want/need to engage locking. Obviously and since Lotus added the functionality, it was something a great number of people requested.
Maybe you'd like some beads to go with that work-puddle diversion dance? (**sound of drums and chanting**room filling with smoke**omygosh! I can't see the question anymore!!!***)
IMHO, Notes is not suitable for multiple parallel updates possibly happening on remote replica databases. Work-puddles are therefore bound to fail. Locking will help a lot, but still it should never be an initial requirement for a workFLOW application to use locking. I still think it's a lack of organization. We should be discussing this over a good glass of wine...
The only methods I can think of that are simple and doable: create a rich-text field per department in the form, with restricted access sections, or response documents per partial task and the parent document reflects the status of all the responses together.
I suppose that work-puddles are quite common in places where it rains a lot...
The only methods I can think of that are simple and doable: create a rich-text field per department in the form, with restricted access sections, or response documents per partial task and the parent document reflects the status of all the responses together.
I suppose that work-puddles are quite common in places where it rains a lot...
>>create a rich-text field per department in the form, with restricted access sections, or response documents per partial task and the parent document reflects the status of all the responses together << agreed this would eliminate replication conflicts since the same fields would not be modified.
You would also have to eliminate the HISTORY, last modified by, and other similar logging fields that so many of these applications employ to avoid replication conflicts.
If you are planning to deploy several replicas across many servers, then you would need to pay more attention to planning and implementaion of your workflow application.
Unfortunately, those that I've had to fix look like glorified spreadsheets, so the only thing that would fix is complete redesign. The other problem the great many customers/clients who insist on shooting themselves in the foot and demand that the application function in a way that produces "work-puddles."
When these things are out of the designer's control, then you seek alternative methods - and locking is one of them.
You would also have to eliminate the HISTORY, last modified by, and other similar logging fields that so many of these applications employ to avoid replication conflicts.
If you are planning to deploy several replicas across many servers, then you would need to pay more attention to planning and implementaion of your workflow application.
Unfortunately, those that I've had to fix look like glorified spreadsheets, so the only thing that would fix is complete redesign. The other problem the great many customers/clients who insist on shooting themselves in the foot and demand that the application function in a way that produces "work-puddles."
When these things are out of the designer's control, then you seek alternative methods - and locking is one of them.
> ... glorified spreadsheets...
Yuck! We seem to agree on that!
Yuck! We seem to agree on that!
gghaleb, bit late on this but this may help assist someone later, on R5 I have seen document locking implemented by creating a response document when the user enters the document - and deleted when the users exits the document. If another user attempts to enter this document, and a response exists, Notes displayed "user xxx is currently editing this document".
I should be able to dig around and locate the code if required.
Broad.
I should be able to dig around and locate the code if required.
Broad.
Hi Broad, I'm always interested...
This is really off-topic but what a hell...
BroadAustralia,
in your idea the problem "comes to light" when the user doesn't have "Delete documents" right in the ACL.
Similar problem is when you save, close and reopen the doc to reload the RTF changes and the user doesn't want to save (to him still "new") document (he clicks "No" in: "Do you want to save your changes?" but, on his surprise, the doc survives)
Don't you agree?
The workaround would be to delete it using an agent signed by db manager (exclude from view using some flag field, which, on the other hand, includes it in the view the agent acts upon), but I don't like that solution.
Marko
BroadAustralia,
in your idea the problem "comes to light" when the user doesn't have "Delete documents" right in the ACL.
Similar problem is when you save, close and reopen the doc to reload the RTF changes and the user doesn't want to save (to him still "new") document (he clicks "No" in: "Do you want to save your changes?" but, on his surprise, the doc survives)
Don't you agree?
The workaround would be to delete it using an agent signed by db manager (exclude from view using some flag field, which, on the other hand, includes it in the view the agent acts upon), but I don't like that solution.
Marko
Agreed, marko and broad. In R5.0.12, my workaround was to simply create a document with the key being the docID and the user being the author. When the user closed the real document, the close event would mark the "lock" doc field: deleteme to deleteme and move it out of the view where an agent could delete it at the end of the week.
ASKER
Hi Broad,
I would be very interested to see the code
Regards,
Ghassan
I would be very interested to see the code
Regards,
Ghassan
gghaleb, you could ask customer service to reopen this question, but since it really is a response to Broad's note, suggest you open another question asking for lockdoc code solutions for R 5.0.12
New question created:
Title: r5 document locking code solutions for R 5.0.12 ( ghassan )
https://www.experts-exchange.com/questions/21827451/r5-document-locking-code-solutions-for-R-5-0-12-ghassan.html
Title: r5 document locking code solutions for R 5.0.12 ( ghassan )
https://www.experts-exchange.com/questions/21827451/r5-document-locking-code-solutions-for-R-5-0-12-ghassan.html
in version 6.5 document locking is available.
Hope this helps,
Marko