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


@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.