xpages partial refresh can't save after replicate local replica

Question

Scenario:

1. User preview xpage for editing in web browser.
2. Developer replicate a local replica to the server.
3. User click save button and trigger save action partial/full refresh

In 8.5.2 crash the whole database based on can't find java design classes. In 8.5.3 no error CS/SS accrued but there are no changes applied to the document. Seems like if you replicate the sessionID is overridden. Is there a way to fix/detect it?

Any ideas?

thx

Daigle

I would start by considering how often and when you have to replicate your changes to production. Expect problems always if you change the design of application while users are using it. – Strudel

Answer 1

It relates to this effect: Meaning of java.lang.ClassCastException: someClass incompatible with someClass.

Simply said, every design change resets XSP engine. Since 8.5.3 you can control it by property "Refresh entire application when design changes" in XPage properties - turning it off (default since that version) will just "soft reset" XSP engine.

Anyway, you may loose some scoped variables and beans. This concludes to some rules to obey:

• Do not allow developers to change design in production during working hours.

• Notify users about the problem (onError event for partial refresh) - Tim's comment explains, that you won't get an error from partial refresh after design change, unfortunately. Simple CSJS code pinging app availability and report problem when app does not respond could work, but I don't advise that: we use "keep alive" control from ExtLib, and troubleshooting in domlog.nsf became a nightmare - it is full of pings (almost all the time - many users keep their browsers open overnight).

• If data are very important, implement auto save mechanism similar to Google apps.

BTW: This effect is similar to time-outed session - partial refreshes will fail and user need to reload the page (and possibly loose edits).

Nonresident

Frantisek, thx for your response but xsp.application.forcefullrefresh doesn't fix the problem and onError doesn't produce any errors. If I can detect it of course I will implement an auto-save mechanism. Any others suggestions? – Daigle

Frantisek's first bullet point above is the key: don't deploy changes while users are active. Doing so replaces the app they are using with a different app -- a similar app, but a different app nonetheless. Hence, a partial refresh event is asking for a response from an app that no longer exists. The setting listed above minimizes the impact but cannot eliminate it. So don't replace the app out from under your users. Establish and follow a change management process that informs users in advance of imminent changes, and implement when impact will be minimal. – Snub