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)
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)
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?
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
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
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:
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 ?
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.
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).