Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] Administrating CDOLocks
[CDO] Administrating CDOLocks [message #1841266] Mon, 10 May 2021 13:46 Go to next message
Robert Schulk is currently offline Robert SchulkFriend
Messages: 144
Registered: July 2015
Senior Member
Quite frequently, we have users that lock some resource and then forget about it, making it unavailable to change for others.
Is there any existing way to release this lock from another (administrator) session?

Also, we find the concept of durable locks very interesting. But this will of course make the inital problem of unattended locks worse ;). Is there any way to release durable locks from another session?
Re: [CDO] Administrating CDOLocks [message #1841285 is a reply to message #1841266] Tue, 11 May 2021 05:33 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
You can delete durable locks on the server console with the "CDOCommandProvider.deletelocks" command.

For everything else you want to do with (any kind of) locks you need to deploy custom code to the server that uses IRepository.getLockingManager(), IView.close(), or ISession.close().

If you want to invoke that custom code from a client machine, you have the following options:

a) Extend the CDOAdmin protocol
b) Use the CDORemoteSessionMessage framework
c) Implement a custom Net4j protocol


Re: [CDO] Administrating CDOLocks [message #1841297 is a reply to message #1841285] Tue, 11 May 2021 11:46 Go to previous messageGo to next message
Robert Schulk is currently offline Robert SchulkFriend
Messages: 144
Registered: July 2015
Senior Member
Thanks so far! I am trying to implement the release of durable locks now. I am triggering the action via the CDORemoteSessionMessage framework which works great so far.

Although I am not quit sure if I release the locks correctly. This is what I currently do:

    private void clearLocks(CDOSession session, String userId, IRepository repository) {
        final InternalSession mySession = (InternalSession) repository.getSessionManager().getSession(session.getSessionID());
        StoreThreadLocal.setSession(mySession);
        try {
            InternalLockManager lm = (InternalLockManager) repository.getLockingManager();
            lm.getLockAreas(userId, new org.eclipse.emf.cdo.common.lock.IDurableLockingManager.LockArea.Handler() {
                @Override
                public boolean handleLockArea(LockArea area) {
                    if (area.getUserID().equals(userId)) {
                        area.getLocks().clear();
                        lm.updateLockArea(area); //this effectively removes the lock. But no unlock notifications are being sent.
                        lm.deleteLockArea(area.getDurableLockingID()); //if I do not delete the lock area, there will be exceptions on the client if the view is currently open
                    }
                    return true;
                }
            });
        } finally {
            StoreThreadLocal.release();
        }
    }


This works so far, but seems a bit hacky. Is it okay this way? Also: I do not get lock notifications on the clients. Can I somehow trigger a notification that the lock was removed?
Re: [CDO] Administrating CDOLocks [message #1841443 is a reply to message #1841297] Mon, 17 May 2021 07:33 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Via https://bugs.eclipse.org/bugs/show_bug.cgi?id=573570 I've provided a few convenience methods in CDOServerUtil that make your code a little simpler:

  private void clearLocks(CDOSession session)
  {
    CDOServerUtil.run(session, () -> {
      InternalLockManager lm = (InternalLockManager)CDOServerUtil.getRepository(session).getLockingManager();
      String userID = session.getUserID();

      lm.getLockAreas(userID, area -> {
        if (area.getUserID().equals(userID))
        {
          area.getLocks().clear();
          lm.updateLockArea(area); // this effectively removes the locks. But no unlock notifications are being sent.
          lm.deleteLockArea(area.getDurableLockingID()); // if I do not delete the lock area, there will be exceptions
                                                         // on the client if the view is currently open
        }

        return true;
      });
    });
  }


Remaining are the following concerns:

1) When locks of a client view X are released on the server the other client views should receive lock notifications.
2) What should happen to view X? If it's durable then it can be an open client view, but it doesn't necessarily have to be open. Should it stay durable (just with all/certain) locks released? Then it should probably be notified about released locks, too. If durability itself is terminated on the server AND if it's open on the client, should that be notified somehow? Or, if the view is open, could it just be closed from the server?
3) What is the exception/stacktrace that you mention during deleteLockArea()?

You see, lots of questions regarding the requirements. What do you think?


Re: [CDO] Administrating CDOLocks [message #1841542 is a reply to message #1841443] Thu, 20 May 2021 09:17 Go to previous messageGo to next message
Robert Schulk is currently offline Robert SchulkFriend
Messages: 144
Registered: July 2015
Senior Member
Thanks for the convenience methods!

1) Yes, I guess that informing the other views would be the correct thing to do. Because the objects are effectively unlocked. I am now using a simple workaround by quickly locking/unlocking the object on the server which then produces the desired notifications.
2)
---2.1) In my opinion, the remote removal of locks requires custom handling on application side anyways. So the view does not need to stay durable. What we do is: once we detect that the lock was remotely removed, a custom mechanism is triggered that saves the affected object to file, closes the view and informs the user about that.
---2.2) For a disconnected durable view: could automatically refreshing the lock states after a reconnection be a solution? Of course, only if automatic lock updates are enabled.
3) The exception happened on our side during an attempt to unlock the remotely unlocked object. I attached the stack trace. But probably, this does not require any further attention because it only happens if we -on the server- only clear the locks and do not delete the lock area. Nevertheless, I attached the stacktrace.
Re: [CDO] Administrating CDOLocks [message #1841812 is a reply to message #1841542] Mon, 31 May 2021 06:29 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
I spent quite a bit of time on this issue now. First I thought it should be solveable quickly, but after some more analysis I get the feeling that there's more to it. It's probably not just a matter of missing lock notifications but also of incorrect cached lock states. I've made a diagram to illustrate the state transitions of the two view types:

index.php/fa/40562/0/

Note that LockingManager.DurableView instances exist only inside the server locking manager and that they contain no information that arbitrary clients can/may use to identify them. In particular the durableLockingID is kind of a secret that only the owning client is aware of. So, when a view transitions from a normal (active) view to a durable (inactive) view, it's unclear how the CDOLockOwners inside distributed CDOLockStates can be represented.

I think the above view transitions need to be reworked in the light of lock notifications and cached lock states. New view state notifications need to be introduced and a way to identify DurableViews (used as CDOLockOwners) needs to be found...

I've consolidated a few internals around LockingManager.DurableView via https://bugs.eclipse.org/bugs/show_bug.cgi?id=573863 , but that's only a tiny first step.


Re: [CDO] Administrating CDOLocks [message #1841967 is a reply to message #1841812] Fri, 04 June 2021 15:29 Go to previous message
Robert Schulk is currently offline Robert SchulkFriend
Messages: 144
Registered: July 2015
Senior Member
Thanks for your investigation!
Regarding the outdated lock cache: we made the observation that the session ID of a CDOLockOwner is not updated after a session reconnection. I created this bugzilla with a test case.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=573658

Were you referring to the same issue or did you find other outdated content?
Previous Topic:[CDO] Saving a CDOResourceFolder to File
Next Topic:Reference a metamodel type from the model
Goto Forum:
  


Current Time: Thu Apr 18 05:49:26 GMT 2024

Powered by FUDForum. Page generated in 0.02132 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top