automatic cleanup of lock-files for closed transactions (2009)

[MVanwalleghem]

Since our migration to mega-2009, it looks like the lock-files are not cleaned up automatically anymore.

As far as I remember in 2007, after transaction closure, lock-files automatically disapeared (if there was no long-lasting transaction remaining)

Since 2009, I notice that the physical lock-files are remaining.  Only when entering administrator , lock-management + refresh, the actual lock-files are removed.

Is this normal behaviour ?  Or is there a setting which can be set for automatic cleaning.  And if not, is there a api-command to initiate this refresh from a script ?

[jhorber · Accepted solution]

Hello

- Do you suggest to clean up the LOCK after a long period (if an object as been locked for 2/3 month)

--> We recommand a regular moninoring (manual administration task).

Functionnaly, no lock should remain if at a given moment, all transactions are dispatched.

If locks remain in this situation, they should be purged using the button 'Check' of the window 'View locks' in MEGA Administration Console.

- If so, would you do that using a script ?

--> You can code a script with Administration APIs.

There are elementary functions (Unlock, Destroylock...) on the object Protection.

However verify that criteria to purge locks are fufilled before deleteting them.

See also http://community.mega.com/t5/custom/page/page-id/mega-kb-solution?sid=50120000000mqSmAAI

[hdrapin]

Is there a best practices on cleaning up the LOCK ?

- Do you suggest to clean up the LOCK after a long period (if an object as been locked for 2/3 month)

- If so, would you do that using a script ?

I haven't find something useful on the MEGA's Doc on this matter, except how behave Locks...

[hdrapin]

Thanks,

What is the meaning for a LOCK that is Unlocked ? why it stays in the list ?

[jhorber]

Technically, as long as there is a lock (locked or unlocked), this lock can prevent an end user to update an objet

He will get a message such as

Object <object type>, <object name> ' is already being modified by <user>since <date>

So it can be useful for the administrator or even the end user to consult the list of remaining locks

What is not a problem is the situation where lock persist while all transactions have been dispatched.

[hdrapin]

We notice that dispatching or refreshing is not enough, the best way to clean up Locks is to quit the application.

By the way, I find the interface of the administration's side of MEGA not easy to read for the Lock... two Kinds of icons appear in front of each line, those in red (closed) and the other. Why encumber the interface with all these lines? We always look at the one with lock closed. Did I missed somthing?

Any guess on why we need the list of all Locks opened?

Regards

[jhorber]

Helloc Hdrapin

Lock can remain if old transaction remain.

Otherwise, this is not a normal situation, whatever the storage (GBMS, RDBMS Oracle, RDBMS SQL Server).

Contact support if you are able to create a new situation where

• A transaction creating a lock L1 is dispatched
• All transactions are refreshed or dispatched
• The lock L1 still persists

You can use the mail or this form to open a case:

http://community.mega.com/t5/custom/page/page-id/mega-support-case

[hdrapin]

Hi,

We have moved to SQL server, since then we noticed that locks need to be cleaned up regularly, is it a normal behavior ?

Thanks

[jhorber · Accepted solution]

Hello Monique

Note that the existence of the lock file can be misleading

A lock can be released (status: 'unlocked') but persist as a file

This prevents concurrent updates for transaction open before the lock was released.

Example (GBMS storage):

User U1 opens a transaction and updates an object O1

  a lock L1 is created

User U2 opens a transaction

  the lock L1 prevents concurrent updates on O1

User U1 dispatches his transaction

   the lock L1 is unlocked but the lock file persist on disk

   the lock stil prevents prevents concurrent updates on O1 for U2

User U3 open a transaction

  the lock does not prevent updates on O1 fur U3

User U2 refreshes his transaction

   the lock L1 is deleted and the lock file is deleted on disk

   then no lock prevents updates on O1 for U2

Contact support if you are able to create a new situation where

• A transaction creating a lock L1 is dispatched
• All transactions are refreshed or dispatched
• The lock L1 still persists

Of course, if a crash ever occurs at dispatch with the MEGA Desktop application, certain locks may be in an invalid state and should be purge from the MEGA Administration console.

[François]

Hello Monique,

Normal behavior on locks, is that they are purged when transaction is dispatch.

Here is the article on API & Locks management for information.

 http://community.mega.com/t5/custom/page/page-id/mega-kb-solution?sid=50120000000mqvLAAQ

About your request on API which can purge locks on repository (globally) we have raised an enhancement request:

R-000425

Please post more information on your subject if you have information to provide.

See you.