GoogleIt Mail IT Print IT PermaLinkSnTT: Avoid [ReturnDocumentUniqueId] in @DbLookup in Notes/Domino 6
09:22:15 PM

I recently had to write some code to generate a list of all of each user's valid SMTP email addresses. In the course of testing, I experienced a server crash, which after quick look at the NSD I chalked up to a fluke and went on. The crash did not recur, but when the code was installed at a customer site, repeated crashes resulted. Fortunately, the crash was on a dedicated server that did not affect users, but all crashes are bad -- and one look at the NSD told me that this was no fluke. Further investigation brought me to this technote which, apart from the fact that it shows some Solaris-specifc extra stuff at the top, matches what I was seeing.

Let's go back to the beginning, though. The task of figuring out all of a user's valid SMTP addresses arises from the fact that, depending on server settings, Domino may accept a wide variety of inbound addresses as valid aliases for a given user. In a nutshell, a column formula in the $Users view, with some simple transformations, determines all the possible valid addresses, but any possible address that would be ambiguous will be rejected. Amibiguity results from the fact that is a possible valid alias for user John Smith, but only if he is the only person in his company with the last name "Smith".

Software that is examining messages outside of the context of a user mailbox needs to duplicate the logic Domino uses, mapping valid addresses to users and rejecting any that are ambiguous. In the case of my application, this had to be done in a computed field formula -- and it had to be done without adding or modifying any views to the Domino Directory. Coming up with the list of possible valid addresses is no problem at all in @formula language, but weeding out the ambiguous ones requires looping through the possible values, checking for duplicates via an @DbLookup to $Users. This, again, is not a difficult problem, as the server where this will run is Domino 6, and a little bit of @Transform code takes care of it. A further complication arises, however, from the fact that even if there's only one hit in the $Users view, you have to figure out whether the hit that you found is in the index from a previous save of the current document, or is actually a different document. I'm sure that many of you have dealt with the problem of using a view lookup to reliably test for uniqueness of a value in a variety of ways in the past, as have I, but remember that I said that couldn't add or modiy any views -- and I also couldn't assume that @DocumentUniqueId was stored in a field in user Person documents.

Fortunately, this type of situation is a perfect fit for use of the [ReturnDocumentUniqueID] option in @DbLookup, so that's what I selected. Unfortunately, an agent running in the Domino Directory was updating Person documents and calling ComputeWithForm. That triggered the computed field formula containing the @DbLookup with the [ReturnDocumentUniqueId] argument, and that caused the crash.

The lesson of this is not just to avoid @DbLookups with [ReturnDocumentUniqueId] and not just in agents that run server-side as you might infer from the fact that the technote refers to server crashes. In fact, the technote advises avoiding all use of [ReturnDocumentUniqueId], and I have to agree. If there's any chance that an agent might do a ComputeWithForm call that trigger the field formula to do the @DbLookup, you're at risk of a crash.

Note, by the way, that the technote say that the crash does not occur on Domino 7.

Anyone care to guess, by the way, how I modified my code to avoid the crash? It's still @formula language, and I could not violate the contraints mentioned above. I did accept what I'd have to call a small window of potential inaccuracy. Does that give you a good enough hint? If it does, perhaps you might even have a suggestion for a better way. Let me know if you think you do.

This page has been accessed 1064 times. .
Comments :v

1. Damien Katz08/29/2006 10:57:32 PM

Yikes! That's certainly my bug. I added the call, and I must have not accounted for something in the NIF code interaction. It's wicked complicated. Sigh.

Oh well, I hope I didn't cause you too much trouble. Sorry.

2. Peter Herrmann08/31/2006 04:13:12 AM

Assuming Fullname[1] is unique in your environment, you could use that instead of the UNID. Alternatively, you could stop your agent from running if the $Users view contains replication conflicts (the technote says it only occurs in that condition).
Cheers, Peter.

3. vesoftware11/05/2013 10:26:27 PM

Agen Bola Promo 100% SBOBET IBCBET Casino Poker Tangkas Online
ITUPOKER.COM AGEN POKER ONLINE INDONESIA TERPERCAYA : Toko belanja online murah, Promo heboh jual barang hanya Rp 1,-

4. 51316914103/03/2016 08:57:21 PM

5. lllllyuan05/16/2016 12:01:44 AM


6. dongdong806/29/2017 12:02:13 AM lauren.html

Enter Comments^

Email addresses provided are not made available on this site.

You can use UUB Code in your posts.

[b]bold[/b]  [i]italic[/i]  [u]underline[/u]  [s]strikethrough[/s]

URL's will be automatically converted to Links

:-x :cry: :laugh: :-( :cool: :huh: :-) :angry: :-D ;-) :-p :grin: :rolleyes: :-\ :emb: :lips: :-o
bold italic underline Strikethrough

Remember me    

Monthly Archive
Responses Elsewhere

About The Schwartz


All opinions expressed here are my own, and do not represent positions of my employer.