Lock/unlock mecahnism documention ??

[haddad_i]

Hello all,

After a long search I have not been able to find the appropriate documentation regarding the lock/unlock mechanism on objects and diagrams. Can anyone indicate me where I can find this information ?

Moreover, to my understanding and after playing around with the tool to infer the rules of the locking mechanism (given that no documentation seems to be available)  it seems to me that there are two distinct and not completely consistent locking mechanisms:

1) Automatic locks set by MEGA on diagrams (on opening) and on obejcts (on modifications). These locks are released automaticallay on dispatch and can be managed from the View Locks utility. Automatic locks on object only apply to the current object and not its child elements.

2) Manual locks on obejcts via the righ-click > Manage > lock. Manual locks apply to the current object and its child elements. This locks are visible from the View Locks utility when locking, BUT NOT when unlocking (right-click > Manage > unlock). Why is that ? It is as if they are distinct locks but at some point the manual lock is shown in the View Locks window as for Automatic locks.

To sum up, it is completely confusing to use both approaches. How are we supposed to use the lock/unlock mechanism within MEGA ? From a (non tool specialist)  user point of view this is quite unacceptable and disappointing.

I am working on HOPEX V1R3 VP16 (GBMS file system)

Regards,

Ismael Haddad

[jhorber]

Implementation of current locks is different with GBMS storage and RDBMS storage (SQL Server, Oracle)

Behavior is more strict and reliable with RDBMS storage. Technical locking of diagrams has been improved with recent versons.

Note also that GBMS storage is deprecated and that HOPEX V1R3 is at the end of its life.

http://community.mega.com/t5/General-Information/Support-Policy/ta-p/6216

If you use HOPEX V1R3 GBMS storage, I suggest you test HOPEX V2 or HOPEX V2R1 with RDBMS storage. A new licesne will be required, discuss this with your accunt manager.

If you still want to use HOPEX V1R3 GBMS storage, you have still the option to declare the error you can replicate by opening a case (send a scenario).

[haddad_i]

Hello Jerome,

thank you for the info. Actually we are interested in using "concurrent locks" to allow several users to work collaboratively in a single Repository. We are trying to figure out the behavior of concurrent locks, and as far as we have tested, we found that concurrent locks suffer from a certain number of limitations:

• A locked object, can still be edited by other users! That is, other users can create connections from/to the object, can add child elements, add properties, ...
  • the only thing that the lock is preventing is to change the name of the object
• No possibility to open a digram in read-only mode, that is without locking it so other users can work on it.
• When working on a diagram detailing an object, the object itself as well as other child elements are not locked, meaning that other users can edit them leading to potential conflicts

Do you know if thre is any associated documentation explaining theses aspects?

Do you know if concurrent locks on RDBMS storage system solves the issues above ?

Regards,

Ismael

[jhorber]

Hello

Concurrent locks are a platform feature.

It is not really an option to no use them

For functional locks, you can find documentation in the various user manuals

• MEGA Common Features EN.pdf: managing objects versions
• HOPEX Collaboration Manager - Communiquer dans MEGA.pdf: collaborative workspaces
• HOPEX Collaboration Manager - Workflows.pdf: Unlocking request

For HOPEX V1R3, user manuals are available in this page http://community.mega.com/t5/HOPEX-V1R2-V1R3/HOPEX-V1R2-V1R3-Product-Manuals/ta-p/8063

[haddad_i]

Hello Jerome,

Thank you for your answer and reactivity.

 Can you point me  to the corresponding documentation of both kinds of locks you mention, so I can make an informed decision on which one to use  to suit our needs?

Regards,

Ismael

[jhorber]

Hello Ismael

Here are some indications that can help.

The are 2 categories of locks

1) Concurrent locks

They prevent possible inconsistencies due to concurrent updates. They are managed by the system (low level).

The behavior varies with the stockage. With SQL Server and Oracle, deletion of lock is not possible: only dispatch/refresh of private worskpace can free locks.

They are displayed in the administration consoles (Web Administration Desktop, administration.exe)

2) Functional locks

They enable to prevent updates after user decision (workflow, menu lock...).

They are based on immutability mechasnism (logical level).

They are not displayed in all administration consoles (displayed in Web Administration Desktop, not in administration.exe)

Note that GBMS stockage is deprecated. We encourage you to switch to RDBMS storage (SQL server, Oracle)