Community
Participate
Working Groups
As explained in the post located at http://www.eclipse.org/forums/index.php/t/242998/, CDO should provide API methods to get all CDOObjects currently locked by a CDOTransaction : CDOID CDOTransaction.getLockedElements() it should be better to return CDOIds for 2 reasons : - avoid to load the CDOObject when browsing through the locked elements list - allows to reference locked elements that have been detached of the transaction another nice API feature would be a method that allows to get all elements locked by a given user. I do not now what is the best place to define such a feature.
A few comments: (1) Please name the method #getLockedObjects instead of #getLockedElements, to keep the terminology consistent (CDOObjects are not called 'elements' anywhere in the existing API). (2) > another nice API feature would be a method that allows to get > all elements locked by a given user. Locks are owned by users only indirectly, through views. Therefore I think this is best implemented with an additional method allowing all views to be retrieved for a given user. For each of those views all locked object IDs can then be retrieved with a method similar to the #getLockedObjects proposed earlier. I wonder if perhaps the latter methods (the ones for getting locks owned by *other* users) should go into an administrative interface instead of being added to the regular CDOSession and/or CDOView interfaces. We could add more admin features to such an admin API later, e.g. forced lock removal. Something like CDOSession.getAdminConsole() perhaps?
Moving to 4.1. I like CDOSession.getAdminConsole()! However for querying all sessions of a user by userID or for querying all views of such a "remote" session there seems to be a suitable place already, the CDORemoteSessionManager.
(In reply to comment #2) > However for querying all sessions of a user by userID or for querying all views > of such a "remote" session there seems to be a suitable place already, the > CDORemoteSessionManager. Not sure, though, how durable views would be handled as the purpose of the CDORemoteSessionManager is clearly to provide an interface to users (sessions!) that are ready to receive messages and possibly react to these messages.
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
Moving all outstanding enhancements to 4.3
Working on https://bugs.eclipse.org/bugs/show_bug.cgi?id=439337, I have submit 2 Gerrit change-set which provides API for this feature request : https://git.eclipse.org/r/#/c/29894/ : improve LockStateRequest/LockStateIndication network communication overhead https://git.eclipse.org/r/#/c/29895/ : update the behavoir of CDOView.getLockStates() to return all locked objects, locked by current CDOView or others, when an empty collection is in parameter. The advantage is that we use an existing API. Remains to update CDOLockStates cache of other views of current CDOSession when getting its CDOLockStates from the server, but only for CDOView with lockNotification option enabled. I'll submit another Gerrit change-set for that.
Moving all open enhancement requests to 4.4
Fixed as 43fe7cfded275cd7857112cc91d85b8f6fc52783 .
Closing.
