IBM Notes and Domino Application Development wiki: Programming: Actual/uncached reading of profile document fields with lotusscript

Actual/uncached reading of profile document fields with lotusscript

Added by

Christoph M. Noetzli on November 2, 2009 | Version 1

Edit
More Actions ▼

4 comments

Abstract

No abstract provided.

Tags: profile documents, caching, LotusScript

I often read that profile documents are problematic as their major benefit is also their worst problem - caching.
There is a simple solution to that problem, which I extensively use. I’m a big fan of profile documents as they allow to share environment information very efficiently and also to tailor applications having one single application template for very different databases according to the needs of departments and groups. As we know caching is session based, which implements that if you open a session to read a specific value from a profile document, you read what at that moment is actually the value of that field independent who, how and when it was last updated. As I have several databases reading/writing in profile documents of other databases as well as in their own, sometimes an overlapping of running agents trying to read or write the same value in a specific profile document might happen. To make sure that just one agent works on a specific profile document at the time I set up the following function:

<<<<
Function GetProfileValue(Server As String, RepID As String, ProfileName As String, FieldName As String) As Variant
Dim NCProfDoc As NotesDocument
Dim NCSession As New NotesSession

Dim ncdb As New NotesDatabase("","")
If ncdb.OpenByReplicaID(Server,RepID) Then
Set NCProfDoc = ncdb.GetProfileDocument(ProfileName)
GetProfileValue = NCProfDoc.getitemvalue(FieldName)
Else
GetProfileValue = ""
End If

End Function

This function is in all my databases part of the script library and simply called “NoCache”.

As explained I use this function in my lotus scripts to make sure that the concurrent agents are “waiting” until another agent has finished his job. To make sure that all the agents know what’s going on I simple “lock” the specific filed in the profile document by setting its first value to “locked”. As long as this value is locked, a loop is going to check the value until it is unlocked by the running agent with control of that field. I just want to show here the part of the script where the value reading is made:

<<<<
If Not(cdbProfDoc Is Nothing) And (count = 0) Then
SCU = ";" + Join(Fulltrim(GetProfileValue(MServer,Left(RepID,8) + Right(RepID,8),"Database Profile","SC_Users")),";") + ";"
While Instr(SCU,";locked;") And (count < 300)
If (ACLL(0) = "Yes") And (count Mod 30 = 0) Then
Call ACLLog.LogError(0,"Agent is waiting as user list is locked in database " + cdb.Title)
End If
count = count + 1
Sleep (1)
SCU = ";" + Join(Fulltrim(GetProfileValue(MServer,Left(RepID,8) + Right(RepID,8),"Database Profile","SC_Users")),";") + ";"
Wend
If (count > 0) And (ACLL(0) = "Yes") Then
Call ACLLog.LogError(0,"Agent was restarted after the user list was unlocked in database " + cdb.Title)
End If
count = 0
End If

As you can see from that formula, I can use that function to read any list of values (in this case “SC_Users”) in any profile document (in this case “Database Profile”) in any database (in this case having the Replication ID stored in a variable called “RepID”, which must be a valid Replica ID given as a string) on any server (in this case having the name of the server stored in a variable called “MServer”, which could also be an empty string if your agent is running on the same server than the database to be read from). I read the list of values into a single string variable separating the values with “;”, this could be done in any other way as well.

If an agent has to lock the value to make sure that he is the only one writing to the list of values this is done by the following sequence:

<<<<
If count = 0 Then
cdbProfDoc.SC_Users = Fulltrim(Split("locked" + SCU,";"))
Call cdbProfDoc.Save(True, False, False)
End If
count = count + 1

Where cdbProfDoc was set to be the same profile document as read with the function “GetProfileValue”.

At the end the agent is unlocking the value by the following sequence:

<<<<
If count > 0 Then
While Instr(SCU,";locked;")
SCU = Fulltrim(Strleft(SCU,";locked;") + ";" + Strright(SCU,";locked;"))
Wend
cdbProfDoc.SC_Users = Fulltrim(Split(SCU,";"))
End If

The presented function can be used in any agent or other lotusscript feature at any time to make sure that the user gets actual data from the profile document, when this is a need.

Edit
More Actions ▼

Attachments (0)

Versions (1)

Comments (4)

Andre Guirard commented on Jan 12, 2009

Re: Abandoned profiles

You should be able to use profile documents in this way. I wonder whether there might be duplicate profile documents and your agent is updating one while users see the other. This tool may be helpful: { Link }

Gregg Bendtsen commented on Dec 11, 2008

Abandoned profiles

In one of our databases, we have a single agent process that, once a month, updates two fields on a profile document. when someone tries to use code that accesses that profile document field, the new value will not be available, regardless of how long after they try it (one minute, eight hours, two days). If we test the code by running it manually, the new value is available.

Therefore, we have concluded that profile documents cannot be updated by backend scheduled agents. Can you give me the magic tip that makes the backend agent do the same thing as the same agent run by a Notes Client?

(FYI - we have already re-architected this to be a Notes document, but have not yet implemented. If we had the magic tip, we would all feel better because we would then be using profile documents, which appear to be the 'preferred', but in our experience, unreliable way to carry this information in the database.)

Andre: As always, any comments from you are greatly appreciated.

Vladimir Panov commented on Nov 27, 2008

Untitled

@1 Profiles are cached in the database context. So opening new database object may prevent caching.

Andre Guirard commented on Nov 26, 2008

Not sure how this deals with the issue of caching.

Profile documents are not an appropriate place to store frequently-updated information. Nothing you can do will change this. The above is not a reliable way to make sure everyone has the same information.

That said, I have some detailed comments about your approach which may inform your other development work.

You might more easily prevent conflicting updates using the CodeLock function, as opposed to setting a field. Between your testing a field and setting it to show you have a lock, another thread could test and set it. The result is that both threads think they have a lock.

Also, when you do have a loop waiting for something to happen, use the Yield statement in the loop. Otherwise, you're slowing down the event you're waiting for. You hog all the CPU resources by repeatedly checking, preventing another process from getting the work done.

I don't get how this deals with the issue of caching. Instead, it _takes advantage of_ caching by assuming that agents will see changes made by other agents. It works OK as long as there's only one server process accessing the profile document (and hence, only one cached copy that they share), but as the server supports more threads, it may have multiple independent cached copies of the profile. To make sure your profile document (or any other document, but especially profile) is always up to date, you must use the Delete statement when you're done with it, to prevent getting the cached value the next time you read it.

Copy and paste this wiki markup to link to this article from another article in this wiki.

Link:

About the Original Author

Recent articles by this author

Actual/uncached reading of profile document fields with lotusscript