One reason it's so efficient, however, is that it skips the standard view serialization. Remember, when I talk about views in relation to XPages, I'm almost always referring to the V in MVC, not the Domino index design element. In 8.5.2 and above, the default page persistence setting is to "keep pages on disk". When this option is selected (or left as the default), one of the last operations performed when a user accesses an XPage is serialization of the component tree hierarchy to the server's temporary folder on the local hard drive. Everything that the server knows about the page state - values of fields, properties of read-only components, etc. - gets flushed to flat files on disk, allowing the server to "forget" all of that... literally: once written to disk, it can be removed from memory.
If the user triggers some event against the rendered instance of that page, the request parameters sent to the server include enough information for it to locate that state information on its hard drive and parse it all back into memory. Assuming your server has post-millennial hardware, this all still typically happens in a matter of milliseconds, but there is an incremental lag caused by the disk I/O, which is the price paid for increased scalability; the alternative to this process is to hold all these page states in memory, so the more concurrent users you have, the sooner your RAM would vanish. If you've got enough RAM, of course, you can change the default behavior to an alternate option with more rapid response time. Changing it to "keep pages in memory", for example, forgoes serialization entirely. This causes events to fire more rapidly, because the server "remembers" the full page state (because it's still in RAM), so it doesn't have to go to disk to reconstitute the component tree prior to responding to the event. As a consequence, however, the state of all these pages lingers in memory long after each ceases to be needed.
The compromise setting is to "keep only the current page in memory". When this option is selected, the server only stores one component tree at a time for each user. When a user accesses a page, it renders the markup, but leaves the view state in RAM. Every event fired against that view instance is accessing that in-memory component tree state. As soon as the user navigates to another page, it serializes the previous page to disk, then constructs the new page in memory (and leaves it there until the next navigation event). If the navigation to a new page was not the result of leaving the page, but instead loading a different page in a new browser window (or tab), then it's conceivable that the user might close that new window and continue interacting with the original page. In this scenario, the server is then able to reconstitute the state of that page using the same process it would follow were it keeping all pages on disk. If, however, it was a typical navigation event (moving from one page to another within the same window), then the state of the first page will never be needed again. It's still there on disk, but will get automatically flushed once the user's session expires. In my opinion, this setting should be the default, because it provides excellent per-page performance without wasting RAM.
But what if it isn't? What if the behavior of your RPC method does alter the state of a component or values in a data source? If your application keeps the current page (or all pages) in memory, it doesn't matter, because whatever changes you're making are altering the in-memory view state, and any subsequent events will access that same in-memory state. But if you're using the default option to keep all pages on disk, because all RPC methods skip the step that saves the component state, your changes are lost... unless you force this serialization to occur anyway. The good news is that, while this might sound complex, it's quite easy.
In any RPC method that does make changes to component properties or data source values, at any point after all of those modifications are complete, add the following operation:
var app = facesContext.getApplication(); var stateManager = app.getStateManager(); stateManager.saveSerializedView(facesContext);
This forces the current view state to be written to disk, just as it would during a normal event. Ergo, any subsequent event is interacting with the page as you last left it, with any changes made by the RPC still intact.
locating XPage components with XspQuery
Sun, Apr 14th 2013 12:00a Tim Tripcony Several years ago, I wrote a utility Java class designed to make it easy to search for components within the current XPage instance based on various criteria. I've found it enormously useful, and, apparently, so has Keith Strickland, because he added it to org.openntf.xsp.extlib, complete with a few refinements. As an example of how you might use this, examine the following line of code:
List requiredFields = new XspQuery()
.loc [read] Keywords: ldd
your how is not your what
Wed, Apr 3rd 2013 11:36a Tim Tripcony I've noticed a pattern emerging when I'm asked for help with XPages. Here's a representative conversation:
"I'm trying to do [X] and it's not working. How can I do that?"
"What are you trying to accomplish?"
"I already told you. I'm trying to do [X]."
"No, that's how you're trying to do it. What are you trying to do?"
For example, replace "[X]" with "reach into a repeat control from outside it" (since this has become the most frequent topic I'm asked about [read] Keywords: xpages application
my new favorite quote
Sat, Mar 23rd 2013 5:20p Tim Tripcony "We go about our daily lives understanding almost nothing of the world. We give little thought to the machinery that generates the sunlight that makes life possible, to the gravity that glues us to an earth that would otherwise send us spinning off into space, or the atoms of which we are made and on whose stability we fundamentally depend. Except for children (who don’t know enough not to ask the important questions), few of us spend much time wondering why nature is the way it is; where the [read] Keywords: wiki
Taking the scary out of Java in XPages: Prologue
Tue, Feb 26th 2013 9:50p Tim Tripcony The discussion following my last post made stark the need for greater availability of information that makes the nature of Java more accessible to Domino developers. Credit for the title of this post goes to Declan, who is considering writing a series of blog posts on this topic. I will be doing the same; hopefully there will be a fair amount of duplication. As David Leedy is fond of stating, it's a good thing when several people share the same information, because that makes it easier for the [read] Keywords: domino
Passthru vs. component - my perspective
Sat, Feb 16th 2013 9:40p Tim Tripcony Paul Withers posted a thorough article explaining the differences between namespaced XPage components (e.g. ) and their corresponding passthru elements (e.g. ), providing numerous examples of what actually happens when these objects are constructed. I've always heard (and often repeated) that passthru elements are more efficiently processed than their namespaced equivalents, so Paul's post inspired me to offer my own perspective.
Simply put, there's practically no difference... but there a [read] Keywords: acl