As a folow up of this thread : started by Nicolas Wallner.
When Transaction Logging is enabled in a db, and you have some LS-code that creates a NotesDocumentCollection, it looks like all content in these documents is held in memory. If a user changes and saves one of those documents after the collection is created, and before this code (re)saves the document, all user changes are lost.
You can see example code here :
This behaviour does not occur when Transaction Logging is disabled.
This can have serious implications on how your code works, and can make changes go lost without any notice.
I have tested this on a Win2000SP4 - ND6.02CF2 - server. It would be nice if others could confirm this behaviour.
Subject: RE: Different behaviour of NotesDocumentCollection when Transaction Logging is enabled/disabled with possible loss of data
There may be some difference in when the document is read from disk depending on whether transaction logging is enabled. However, this only increases or decreases your odds of a conflict with user editing. It’s perfectly possible for a new version of a document to be saved by a user while your agent is working on it even if the document was just read from disk.
To avoid all chance of this occurring, you must use the Save argument that tests whether there is a save conflict and aborts the save. Something like this:
set nextdoc = coll.getnextdocument(doc)
Do
’ do your document processing here.
savedOK = doc.Save(False, False)
if Not savedOK then ’ probable save conflict.
’ get the document out of memory and read it again from disk.
strTemp = doc.NoteID
delete doc
set doc = db.GetDocumentByID(strTemp)
end if
loop until savedOK
set doc = nextdoc
Disclaimer: this is just off the top of my head; you probably should do something to prevent an infinite loop in case the save fails for some reason other than a user editing the document.
Subject: No, this is not about save conflicts! Please give your opinion here, Andre.
Andre,
This behaviour can make updates go lost without there being any reason to have a save conflict!
Watch this :
Agent creates NotesDocumentCollection
User opens a document thats in the collection and updates field ‘Field_A’
User saves document
Agent fetches same document that the user allready has saved!
Agents updates field ‘Field_B’ (in fact it doesn’t have to change anything, saving the document is enough)
Agent saves the document → There is no reason for a save conflict here, because the user had already closed and saved this document before the agent fetched the document.
The update of field ‘Field_A’ by the user is lost.
Subject: RE: No, this is not about save conflicts! Please give your opinion here, Andre.
I’m not going to spend time trying to prove whether this a bug myself, but if you can prove it I will write the SPR. If you try the code I posted and it doesn’t help, then we can talk.
It’s not entirely clear what’s happening behind the scenes. You think that Notes is “fetching” the document when you call GetNextDocument. I think it’s possible that when transaction logging is used, Notes is fetching all the documents when you do the query that creates the collection, and holding them all in memory until you ask for them. So, edits that happen between the time you enter the loop and the time you “get” the document, are not reflected in the document that you end up with. However, the Save method should still notice whether the document you are saving is in conflict with the document on disk, and you should still be able to fetch the current version of the document and repeat your changes on that.
Subject: RE: No, this is not about save conflicts! Please give your opinion here, Andre.
[I think it’s possible that when transaction logging is used, Notes is
fetching all the documents when you do the query that creates the collection,
and holding them all in memory until you ask for them. ]
If that’s the case, then that’s the bug. Nowhere in any documentation nor in
any historic behavior of Notes does this sort of quasi-caching take place. It
would be stupid to do so. In what transaction logging system anywhere at
anytime has “get me this record” meant “get me a version of this record as of
the start of this process?”
In other words, if the document is not “fetched” at the exact time of the
GetNextDocument call, then that’s a bug – plain and simple. If Lotus wishes
to introduce a .GetNextDocumentCached call, then that can appropriately be a
new method to the collection object.
Subject: RE: No, this is not about save conflicts! Please give your opinion here, Andre.
Perhaps you are right. However, there’s an important difference between the two situations; in one case I’m willing to test it myself and write the SPR.
I’m a volunteer here, and anyway this is not my product area. I’m not interested in further discussion and opinion on what is and is not a bug – only additional facts. I’ve said what I’m willing to do and the conditions under which I would do it.
In any case, Support can really get more action for you than I can. All I can do is try to persuade.
I cannot reproduce this behaviour anymore …Whatever I do, everything seems to work like it should, transaction enabled or not. So there must be some other parameter involved too.
It stopped after I had tested on this item through a web client. When I did the user updates via the web, everything seemed to work ok. Afterwards, I couldn’t reproduce the problem in any way…
Right now I don’t have time to test further but I will some other time.
Perhaps Mr. Wallner can share his futher experiences too ?