I am new to LN. Could anyone explain to me some basic mechanism of LN? What exactly happens on the server and the client when opening a .nsf file from a user workstation? How are all documents, views and forms ect. generated and where they reside? What happens if multiple users request and modify the same .nsf file? Thanks a lot!
Billy
Subject: See “Inside Notes: The Architecture of Notes and the Domino Server”
Subject: RE: See “Inside Notes: The Architecture of Notes and the Domino Server”
Thanks Alan. It is a very detailed document. However, it will be nice if someone can give me a brief instroduction of my questions.
Billy
Subject: RE: See “Inside Notes: The Architecture of Notes and the Domino Server”
Try this free tutorial:
https://www6.software.ibm.com/reg/devworks/dw-lsdom6adm-i?S_TACT=103AMW13&S_CMP=LDD
Stephen Lister
Subject: RE: See “Inside Notes: The Architecture of Notes and the Domino Server”
Thanks Stephen.
Subject: Some brief responses
What exactly happens on the server and the client when opening a .nsf file from a user workstation?
Alot, especially when you first login. But let’s ignore login for a moment.
There’s a “launch” setting on the database that says what the server’s going to attempt when you first open the database. That “launch” setting defaults to an “open as last” setting, which will open a view to the last view you had opened when you last closed the database. In this case there’s also a “default” view that the client will open, first. In most other cases, you’re opening up a specific design element: a view, a page, a frameset.
How are all documents, views and forms ect. generated and where they reside?
Docs are generated and reside in the particular application database file, the “nsf”. It’s a “sufficient” repository, you can move that file around and it’ll have all the shared data needed to restage the database. Every other file can be generated from it.
If you create PRIVATE design elements, they won’t move around this way. They’re actually stored with your client.
What happens if multiple users request and modify the same .nsf file?
Well, if you have a server in between, the multiple users request and modify the same .nsf file, no problem.
If two users try to modify the same document, though, they can generate save conflict documents. These are different versions of a document. The conflict has a “second version” of the same data, so nothing’s lost. However, it’s often a manual task to resolve the save conflict. So often it’s not worth the trouble to save the document. I normally cancel a save when I’m warned that a save conflict will result.
If you change a document locally, say, and someone else changes the same document on a replica of that database on a server, when you resync the databases, a replication conflict document will result. It’s the same kind as a save conflict: a document with the same data as you’ve saved it.
ND6 has certain special features you can enable to destroy replica conflicts automatically. These are important to have, but don’t turn them on without thinking through their impact, or you’ll destroy data you might very well want. They can be useful only in situations where “the updates don’t matter”, that is, somehow the latest update to the document doesn’t really need any intervening update that it’s ignoring. So … don’t turn on this special feature unless you’re supremely confident the rep conflict document never has useful data.
You can leave conflicts out of a view by selecting against them, they have a “$Conflict” field.
Subject: RE: Some brief responses
Thanks Mike! It helps me a lot.
So what files are copied to the client memory? All documents, views, forms and etc? When and how do they sync with the server files?
What are differences when run an agent locally and on the server? Why can manually invoked agents only run on the client side?
Subject: Agent operations
“What are differences when run an agent locally and on the server? Why can manually invoked agents only run on the client side?”
You’re asking for a lotta detail, some of which it’s unlikely you really wanna know. So if you’re intending to do something, it might be useful to me to know what it is you’re aiming at.
There’s local immediate agents; there’s local scheduled agents, there’s server-based scheduled agents, and there’s also (probably what you’re lookin’ for) immediate “run-on-server” agents. Each has capabilities and access controls designed for their contexts. Yeah, it takes awhile to get used to those specific capabilities.
Server, Scheduled agents:
They run with the signer’s access controls. They also have their own server-level restrictions in the server’s Server document (in the Address Book). “Unrestricted” agents can access the server’s operating system, too.
In ND6 the server can “run on behalf of” that user to access data from yet a third server; in R5, this version of “impersonation” wasn’t permitted, as it’s pretty mind-bending and a bit complicated to implement, I’m sure!
Local, Scheduled agents:
They run with the local client’s access controls. These are kinda like “scheduled, personal agents”, so they have network access that the ID has, and they use it. They also have the ability to access the workstations disks and such, so technically they’re “unrestricted”.
Local, triggered agents:
They run with the local client’s access controls. In addition, they can actually ditz with the Notes client they’re running on, so they can take advantage of the user’s context (what documents are selected? What view am I in?). They can also operate the NotesUI classes because of this, too. They also have the ability to access the workstations disks and such, so they’re technically “unrestricted”.
Local triggered agents are subject to ECLs, though, allowing the user to permit or prohibit them from running.
Server, triggered agents:
They run with the signer’s access controls. I don’t have an Address Book in front of me, so I can’t remember if they have specific “server” restrictions, too. I doubt they do.
Manually-invoked agents can indeed run on the server side, so “I dunno” what the issue is, in particular there. But I can guess.
Only “run once” or “run on entire database” agents can be launched on-demand at the server. The server isn’t handed the client’s view selections, or view location, or the like.
Subject: RE: Agent operations
Wow, you are really knowledgeable!Originally I tried to do such: When a user clicks a button, a server agent will be invoked, then extenal data(via ODBC) will be fetched and all documents on server should be updated. I found out I am not able to specify the server when designing manually-triggered agents. Therefore, I may just create scheduled agents on the server to do the job.
Subject: RunOnServer agents
OK, I think I’ve done what you’re trying to (with a little help from my ODBC friends), so lemme see if I can describe how it’d work. You want to use a server-agent to pull in RDBMS data via connector or ODBC, right?
If so, you’d need two agents. First agent will find the agent that populates via ODBC, then issue the NotesAgent.RunOnServer call. First agent has to obtain the agent to RunOnServer, from the replica of the database that resides on the server. It can’t be the local replica. That’s how you specify what server the agent should run on.
Because you’re using ODBC I’m pretty sure the agent needs to run as an unrestricted LotusScript agent, so make sure you (well, the signer) has the authorization to “run unrestricted LotusScript agents” on the server. An Admin should be able to help you track down this setting in the Address Book (it’s a security restriction in the Servers\Server document for the relevant server).
The server itself has to be set up to handle the ODBC call: ODBC has to be installed and configured so that the SYSTEM task the server runs in, can find it and use it. Otherwise, the ODBC call will simply fail when the server tries to make the call. This seems like a disadvantage unless you consider the alternative: all the Notes clients would have to have ODBC set up for your data sources if you ran the agent directly on them. So, either install ODBC on one server, or install ODBC on many clients.
The RunOnServer agent is particularly hard to debug, at least before ND6. I haven’t had to tackle a new agent on ND6 yet. It does have a remote debugger, I just haven’t had the chance to try it. In R5, keep the agent simple, make sure it runs as a scheduled agent, and that should make it happy enough to RunOnServer.
You can also “test” the access and execution control of the RunOnServer agent. Domino Designer allows you to test the agent access characteristics. To do this, open the list of agents in Designer, in the server database. Highlight (don’t open) the agent you will be running on-server. Select “Agent…Test” from the menu. It’ll tell you if there’s some reason why “agent will not run”. If it tells you “agent executed on nn documents” or something like that, then you’re in good shape.
Subject: RE: RunOnServer agents
The DSN of ODBC has to be on the server only. I am able to call amgr on the server to test out the ODBC agent. I think for scheduled agents I should be able to assign it any servers to run on. So only one agent should do the job. I will try it next week. Thank you very much, Mike! Hava a nice weekend!
Subject: Client memory and synchronization
If you replicate a database locally, all design Notes and all data Notes (aka “documents”) are synched with the client database. A Note is loaded into memory when you open it. Design Notes are rewritten by the Designer, the Notes client doesn’t rewrite these, though it does load them into client memory.
When you save a Note to the server as if you’re a client of that server, that’s when it’s updated. You could also save a Note to a local replica: in that case your Notes client acts kind of like a “1-person” server. It’ll then replicate the results up to another server based on your replication page, according to your replication schedule (in your location document).
There’s another object lurking underneath here, too: indexes. Indexes for views are maintained by the server: they don’t replicate.
Private views and folders are always maintained and stored with the local Notes client.
Folder indexes are even more special. The indexes are actually merged together, accumulating all the additions and deletions from different folder updates on different servers. Pretty much “exactly what you want” from folders, even if it sounds complicated. I think you can occasionally “get back” a document that you’d removed from a folder, if you remove it and then add it on one server’s folder, but then remove it from another server’s folder. I’ve found it seldom surprises me, though.
Then there’re attachments. Attachments are a little wierd, they can do unexpected things in specific encryption / ACL situations. Outside that, they replicate between servers as one big blob.