xCP application and concurrency control

jppop

Hello xCP guys,

I would like to know how to handle concurrency data access (two different users trying to edit a business object at the same time) ?

Is there a way to use i_vstamp ?

Thanks,

Jean-Pierre.

PanfilovAB

what is wrong with checkout()/saveLock()/save() ?

jppop

Hi Andrey,

Nothing wrong. It's not the same purpose. More something to do with concurrency pattern and i_v_stamp (as you explain in your blog).

Imagine this use case:

1. The user edits a business object (Edit page).
   The system locks the object.
2. Then, he decides to go and lunch.
3. He meets a friend who make him an offer he can't refuse. He will never go back at the office.
4. The business object is still locked.

What we would like:

1. The user edits a business object. No lock.
2. He clicks the save button, 10 sec after or 10 days after.
3. The system saves its modification or tells him that another guy has modified the object in the meantime. He should be able to continue or abort the modifications.

Thank you.

Alvaro_de_Andres

Why would you want to workaround one of the very basic principle of a CMS?

a) Have an administrator unlock the file

b) Fire the useless user that leaves a "shared" document locked while not being able to unlock it

jppop

May because we are not in the CMS world anymore. We are in the xCP 2 world...

We are not talking about 'files' or 'documents', we manage 'business objects'.

Locking objects is acceptable for long-time operation (such as document edition).

My concern is how to check that the object I want to save has not changed since it was loaded. The Content server uses the attribute i_vstamp to check this.

For example, let's create an application with xCP.  Create a simple business object (say a Person with a name). Add the creation, edition pages and a page to list the existing Person objects. Deploy the application. Create a Person object.

Then edit the person object (just open the edit page and do not save). Ask a colleague to open the same edit page of the same Person object (you can use two different Internet browsers instead of boring a colleague).

Change something in the page and save. Ask your colleague to do the same.

Your modification is lost. And you don't know it. Neither your colleague. You are both sure you have modified the object.

So, it could be acceptable. But sometimes users want to be warned that the object they have loaded (the edit page) has changed when they clic the save button.

PanfilovAB

I bet you have chosen a wrong platform. Look at this:

xCP guys two three months ago got knowledge about normal forms (I bet they didn't read books ever), also they think that xCP got unique features like workflow attachments. Why do you expect they implemented best practices in xCP?

Alvaro_de_Andres

May because we are not in the CMS world anymore. We are in the xCP 2 world...

Marketing. xCP 1/2 is just a client interface that uses Content Server as "engine". As Webtop is, or Taskspace for that matter.

We are not talking about 'files' or 'documents', we manage 'business objects'.

We manage the same objects we've been managing with WDK applications or DFC.

For example, let's create an application with xCP.  Create a simple business object (say a Person with a name). Add the creation, edition pages and a page to list the existing Person objects. Deploy the application. Create a Person object.
Then edit the person object (just open the edit page and do not save). Ask a colleague to open the same edit page of the same Person object (you can use two different Internet browsers instead of boring a colleague).
Change something in the page and save. Ask your colleague to do the same.
Your modification is lost. And you don't know it. Neither your colleague. You are both sure you have modified the object.

I would fill this as a bug and open an SR with EMC... Usually opening the edit page should place the lock in the object, and avoid further modifications made by other sessions (or at least show a message indicating that the object is locked by another user). Maybe EMC expects you (ie: the xCP developer) to check the locking status of the object (I really haven't tried that use case with xCP2) and show a warning message if it is locked

jppop

Not really a bug, a feature request may be.

Previous client applications (WDK based ones) have never locked objets when the users open the properties page. Try with Documentum Administrator.

Alvaro_de_Andres

jean-pierre.franconieri wrote:

Not really a bug, a feature request may be.
Previous client applications (WDK based ones) have never locked objets when the users open the properties page. Try with Documentum Administrator.

Opening the properties windows (in DA) is different (or should be) than opening the edit page from xCP. Other systems that use a similar configuration by edit/view properties windows such as alfresco or nuxeo (I'm pretty sure that they) place the lock on the file when the edit page is loaded.

jppop

Questions I ask myself almost every days

PanfilovAB

You are both wrong. "Lost update" problem successfully solved in most modern frameworks using optimistic locking (even ASP .NET does support optimistic locking). But despite the fact that DFC supports optimistic locking (DFC wasn't designed by EMC) xCP doesn't - xCP objects doesn't contain information about i_vstamp attribute value:

that means that xCP has a design gap.

The WDK case, Jean Pierre is talking about, is just a side effect of caching in WDK/DFC - take a look at com.documentum.webcomponent.library.properties.Properties, it just tries to handle DfException to figure out whether object was modified externally or not.

PanfilovAB

Actually, you can load r_modify_date attribute into a hidden field on a page and implement some validation logic before trying to persist changes, though it seems not to be a straightforward solution - a lot of  "redundant" logic rises out of nowhere.