Seeming data corruption after multiple access to XSet

Question

L.S., We have a question regarding the meaning of the error message 'xam/xset corrupted' in a specific case. One of the ways we are currently using Centera is to provide each of our users with an XSet to store a dataset that changes often. The dataset is one stream of this XSet and after each user session a backup of that user's dataset is made in a separate stream of the same XSet. We are currently working on a tool that can restore one of these backups by copying the backup dataset (i.e. the contents of a backup stream) over the contents of the primary dataset stream. We are using the following scenario to test this tool: already contains a backup B0> 0. The user logs into the system. 1. The user modifies his dataset. 2. The user logs out. 3. The user's session terminates -- his dataset with alteration overwrites the previously stored dataset in Centera and a new backup stream B1 is added. 4. Now the tool is used to restore stream B0. 5. The user logs back in; the change he made in the previous session should have vanished. Unfortunately this is not what we see happening. Instead, we do not see any result from restoring the backup (even though we can see that things have changed when examining the XSet with shxam) and the main system is no longer able to write to the XSet -- when the user logs out again, the attempt to overwrite the dataset and create another backup fails with an error message of 'xam/xset corrupted' (which is incorrect since shxam can access the XSet in question). The next step is even better, though: if we restart the main system, then we see that everything is correct again -- the XSet is readable and writable AND the backup has been restored correctly. When we started building our main system we included pooling of the XSet objects created by the XAM library (at the recommendation of EMC). Since the backup/restore actually does work and a restart of the main system fixes everything, we are wondering whether the problem is caused by the fact that the main system caches XSet objects. Could it be that the EMC XAM library includes some caching, causing us not to see the result of restoring the backup before a full system restart? And could the incorrect 'xset corrupted' error message be the XAM library's way of saying that the XSet object is out- of-sync with the actual XSet on Centera? Thanks in advance for any insight you can provide, The Qiy Development Team.

mckeown_paul · Answer

what do you mean by 'main system' and what other systems are there? XAM doesn't do any caching, when you write to a xstream the content/blob is streamed to the XSystem (centera) and which you commit the xset and receive back the XUID then the XSet is persisted on the XSystem. If however you say opened an XSet added an xstream field and did not do the commit part (e.g. the user logged off before the commit) then when you opened the XSet again then it will not have the last change.  Also remember that when you update an XSet you are creating a new one not actually updating the old one.

Centera

Was this post helpful?