Seeming data corruption after multiple access to XSet

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.