In a web only application, for data that is non volatile, which method is best for application config variables. Best being highest performance.
@Environment or @GetProfileField
Subject: probably here is answer
I would not use any of those methods, but If I had I would select @GetProfileField
@GetProfileField is cached so it is not good for dynamical settings. I mean it could be ok, if you change settings not often.
@Env. - I do not think it is quite good, of you have 100 settings for your app. you notes.ini on server will be like a mass of data.
@ - You can use Profile and and add all setting to one special field. Then this profile field has to go in each document you create. You will increase speed (because you do not need to do any lookup to Notes.ini or Profile, just use field from document and parse values).
// Dmytro
Subject: I use doc-based configuration for everything…
-
I’ve had nothing but grief with profile documents; mainly they simply vanish intermittently for no apparent reason. Every now and again one or another of the production systems used to simply break, and when it did, the profile was missing again. Copying it from another system required code, or that seemed the simplest route, because one can’t simply copy and paste it like a normal document, so the profile was not trivial to restore. They also can’t simply be opened and edited, requiring some dog and pony show to even do that.
-
I got fed up with this and converted everything to doc-based configuration. Once it’s set up, it’s simpler to edit, simpler to add new or remove old configuration values, and it’s not cached so changes made take effect instantly. All my code defaults every possible value, so I only need to configure things that are unique to that system. Now I simply copy and paste the one View, one Form, and one Class to put doc-based configuration in a new application. The Form has a comment field as well, so the configuration explains itself when opened, without scads of clutter of all the other dozens of configuration in the way, and it’s trivial to maintain a last mod date and user for each separate configuration entry.
-
It makes replication a bit trickier, if the replicas require unique settings, but since I started doing doc-based config I’ve never turned back, and the systems have never lost their configuration again.
Hope this helps…
Subject: Please elaborate
on your “they simply vanish intermittently for no apparent reason”
Did the notes really disappear from the dB (eg: you found deletion stubs) or was it they simply vanished from the internal NSF index and were not retrievable via the regular profile doc APIs?
Did you notice any trend or pattern to when or how often this happened? Did the problem occur en-mass or was it more like a land mine field for your users?
Bruce
IBM
Subject: I must apologize, Bruce…
-
It’s been so many years … heck it may even be fixed and I don’t use profiles so I’d never know! (grin) I don’t recall looking for deletion stubs, etc - when a profile “vanished” it simply could no longer be accessed by anything, but in most (if not all) cases “anything” was one form of code or another, either server-side processes or client side buttons/Action menu items. So the actual fate of the profiles could have been any number of things that were never investigated.
-
Taking fully random stab I’d say probably it was no longer accessible using the profile APIs.
-
I don’t recall any particular pattern to the disappearance, either. The application would simply break at odd intervals, we would poke around and find a database that had a profile still, then we’d run an Agent to copy that profile to any missing databases. Usually it was the production system that failed, but it was also the one that received the most use by orders of magnitude, where the dev system would sit for long periods without any activity; all Agents and code completely turned off. Generally it was the dev system we’d copy the profile from.
-
This system is still in production. It’s three replicas in three places around the country, for failover, not for clustering or anything. The dev system is co-located (as in the same server facility) as the primary replica, that being the application that’s used unless it fails for some reason, and that being the system that lost its profile with the by far the greatest frequency.
Hope this makes some measure of sense…
Subject: No apology necessary but
I would like to pick your brain a bit more.
So from your info it looks like it was more of a “mine field” approach to failure rather than a “we lost 53 profile documents?” kind of failure and it was not a consistent failure.
Just how do you utilize Profile documents? Do you generally read often but write rarely? Or does your application read/write with about the same frequency (eg: you use it to track ‘unread marks’ or similar stuff)?
I just want to get an idea of how your profiles are used compared to the systems I know and see if there is any commonality.
Bruce
IBM