Xpages document changing document mode?

Question

I have a strange thing occurring; as usual, I can\'t post code, unfortunately, so I\'m describing the problem in case anyone can suggest a possible cause.

I have an

Answer 1

Maybe check if the server log file has warnings like:

WARNING CLFAD####W: State data not available for /page because no control tree was found in the cache.

If you're seeing those warnings, it could be that the server can no longer find the current XPage page instance in the cache. In that case the page will revert to the initial state, like when the page was first opened. That might be why the document goes to read-only mode.

The session cache of server-side page instances only holds 4 pages when xsp.persistence.mode=basic, or it holds 16 instances when xsp.persistence.mode=file or fileex.

If you load 4 xagent page instances, then that will fill the cache, and it will no longer be able to find the page instance for the current XPage you are viewing. So the XPage will stop performing server-side actions, and partial refresh will always show the initial state of that area of the page.

To avoid that problem, in the xagent page you can set viewState="nostate" on the xp:view tag, so that page instances are not saved for the xagent page, as described here: https://tobysamples.wordpress.com/2014/12/11/no-state-no-problem/

Or else you can create and reuse one page instance for the xagent, so only one is created. That is, on the first call to the XAgent, have the xagent return the $$viewid value for the xagent page instance (#{javascript:view.getUniqueViewId()}), and then in subsequent requests to the xagent use that $$viewid in the request, to restore the existing xagent page instance instead of creating new instances that will fill the cache. So the subsequent xagent requests will be like so:

/myApp.nsf/xagent1.xsp?$$viewid=!aaaaaaaa!

Answer 2

It's hard to troubleshoot without code, but here are a few thoughts:

1. How are you checking document locking? Via a client-side JavaScript AJAX call or an XPages partial refresh? If the latter, what is the refresh area? If the former, what is the refresh area you're passing and the return HTML? Does it always occur when you're in edit mode on a row and the check happens, or independently of that? The key thing to check here is what the check for locking is doing - is it checking the server and returning a message outside the repeat, or checking the server and returning HTML that overwrites what's currently on the browser with defaults, e.g. the document mode as read mode.
2. What network activity is happening between the browser and the server and when? Is something else overwriting the HTML for the row, so resetting the row to read mode.

It's unlikely to be random, the key is going to be identifying the reproduceable steps to identify a common scenario/scenarios and cause.

EDIT Following on from your additional info, is there a rendered property on the Edit link? If that calculates to false in earlier JSF lifecycle phases, the eventHandler is not available to be triggered during the Invoke Application phase. Because the eventHandler also includes the refreshId, there is no refreshId and refreshMode, so it defaults to a full refresh with no SSJS running. See this blog post for clarification http://www.intec.co.uk/view-isrenderingphase-and-buttons/.