Bugzilla – Full Text Bug Listing
| Summary: | Provide the method CDOLock#getOtherLockers() method | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Stephane fournier <stephane.fournier> |
| Component: | cdo.core | Assignee: | Project Inbox <emf.cdo-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | caspar_d, Michal.Tkacz, saulius.tvarijonas, smcduff, stepper |
| Version: | 4.2 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Stephane fournier
Hi, Since Eike solved my issue, I've implemented the suggestion I made to know who is locking an object (to report a message to the end-user). To avoid to modify CDOLock.isObjectLockedByOthers method signature, I introduced a new method named getLockers() (a more appropriate name can be found, please let me know guys). getLockers() method returns all other ones that lock the related object. The return element is a collection of Id : either the Session.getUserId (if any i.e credential is used) or SessionId. On server side, I shared the implementation in RWLockManager.java for isObjectLockedByOthers & getLockers services to avoid code duplication. Indeed, returning an empty collection means no one is locking the object. Let me know what you think about that. Shall we introduce this new method or modify isObjectLockedByOthers as discussed in the bug description ? Stéphane. (In reply to comment #1) > Hi, > Since Eike solved my issue, I've implemented the suggestion I made to know who > is locking an object (to report a message to the end-user). > > To avoid to modify CDOLock.isObjectLockedByOthers method signature, I > introduced a new method named getLockers() (a more appropriate name can be > found, please let me know guys). > > getLockers() method returns all other ones that lock the related object. > The return element is a collection of Id : either the Session.getUserId (if any > i.e credential is used) or SessionId. > The locking is made per CDOView. getLockers should returns the viewid nothing else. From there we could ask more info if we want right ? Make sense ? > On server side, I shared the implementation in RWLockManager.java for > isObjectLockedByOthers & getLockers services to avoid code duplication. > Indeed, returning an empty collection means no one is locking the object. > > Let me know what you think about that. > > Shall we introduce this new method or modify isObjectLockedByOthers as > discussed in the bug description ? getLockers will returns locks from others... or all locks (include the one who is asking ?) > > Stéphane. > (In reply to comment #2) > (In reply to comment #1) > > Hi, > > Since Eike solved my issue, I've implemented the suggestion I made to know who > > is locking an object (to report a message to the end-user). > > > > To avoid to modify CDOLock.isObjectLockedByOthers method signature, I > > introduced a new method named getLockers() (a more appropriate name can be > > found, please let me know guys). > > > > getLockers() method returns all other ones that lock the related object. > > The return element is a collection of Id : either the Session.getUserId (if any > > i.e credential is used) or SessionId. > > > > The locking is made per CDOView. getLockers should returns the viewid nothing > else. From there we could ask more info if we want right ? Make sense ? > I think to clarify the situation, a simple scenario is useful. Scenario : - 2 Eclipse applications running CDO clients (client A & B) on different computers. - a CDO Server application on another computer. - Let's assume, both clients use credentials to connect to the cdo server. 1) Client A gets a write lock on Object 'Dummy'. 2) Client B wants to know who has locked Object 'Dummy' ? Because he wants to modify it and at the moment he can't. So, from client B (on client side), would it be possible with 'client A' view Id (get from getLockers() method) to retrieve more info ? By more info, I mean, userId (the one defined by client A credential). To do that, we need to get the client A IView instance, to call getSession.getUserId() for instance.... In fact the question is : from a view can we access another view info running on a different application instance ? If we can't, we have to retrieve view info on server side because the server has accesses to all views. I'm not a cdo expert, it may be a silly question. > > > On server side, I shared the implementation in RWLockManager.java for > > isObjectLockedByOthers & getLockers services to avoid code duplication. > > Indeed, returning an empty collection means no one is locking the object. > > > > Let me know what you think about that. > > > > Shall we introduce this new method or modify isObjectLockedByOthers as > > discussed in the bug description ? > > getLockers will returns locks from others... or all locks (include the one who > is asking ?) > I think, we can have both, we just need an additional flag in the getLockers method to include or not the requester. > > > > Stéphane. > > > Guys, I like the idea of being able to know who owns a lock and maybe send a message to this person. I think one of the central challenges is this question: How to identify a view in a different client? The viewID alone is not unique over all views of a repository. It is a counter starting from 1 for each session. The combination with the sessionID would be unique over the whole repository. But only for the current runtime instance. In other words, the sessionID starts from 1 with each activation of a repository. For several reasons I would like to have a new sort of viewID that is unique for each view that was created in the whole lifetime of a repository. This will be needed for transactions anyway if we want to explicitly persist transactions / commit operations (for audit reasons, bug 256649). And for the persistent locks feature request (bug 263024) this might become necessary as well. Maybe it makes sense to create a new implementation of CDOView for this purpose, one that has no current state but can serve as an instance for information purposes. Maybe it makes sense to add a narrower super interface to CDOView for this purpose. For the persistent ID of these views, do you think that a long integer is large enough? Should we also make the IDs of the associated sessions persistent? (In reply to comment #4) > Guys, > > I like the idea of being able to know who owns a lock and maybe send a message > to this person. Me too :) > > I think one of the central challenges is this question: How to identify a view > in a different client? > > The viewID alone is not unique over all views of a repository. It is a counter > starting from 1 for each session. > > The combination with the sessionID would be unique over the whole repository. > But only for the current runtime instance. In other words, the sessionID starts > from 1 with each activation of a repository. > > For several reasons I would like to have a new sort of viewID that is unique > for each view that was created in the whole lifetime of a repository. This will > be needed for transactions anyway if we want to explicitly persist transactions > / commit operations (for audit reasons, bug 256649). And for the persistent > locks feature request (bug 263024) this might become necessary as well. > > Maybe it makes sense to create a new implementation of CDOView for this > purpose, one that has no current state but can serve as an instance for > information purposes. Maybe it makes sense to add a narrower super interface to > CDOView for this purpose. > > For the persistent ID of these views, do you think that a long integer is large > enough? > It should be ! Does it make sense to recycle ID when the view has been closed ? > Should we also make the IDs of the associated sessions persistent? > To be honest, I have no idea regarding this point. You are the expert ;) Regarding the schedule, do you think we can get something working in Galileo release train ? (In reply to comment #5) > Regarding the schedule, do you think we can get something working in Galileo > release train ? This mainly depends on your ability to contribute in time :P Since no other project in Galileo depends on CDO, we don't care too much for official feature freeze... (In reply to comment #6) > (In reply to comment #5) > > Regarding the schedule, do you think we can get something working in Galileo > > release train ? > > This mainly depends on your ability to contribute in time :P I was expecting such an answer from you :) Sure, I can contribute some parts, but I don't have enough CDO knowledges to implement all your suggestions by my own. May we work together ? > Since no other project in Galileo depends on CDO, we don't care too much for > official feature freeze... > Sure! If you bare with me for my limited time... I'm thinking about this persistent evidence of sessions and views/transactions. This somehow breaks the former assumption that the repository data is only modified in the scope of transactions. There are also performance and resource consumption concerns... Maybe we should make this a more explicit decision at the client side? Something like a CDOView.getState() / setState()... And we'd need API to "re-open" persisted views on a session. That could match nicely with the pending persistent lock feature: We'd only allow them if CDOView.getState()==State.DURABLE In any case I think a separate Bugzilla should be filed for this "persistent view" thing. Rebasing all unresolved enhancement requests to 3.0 Rebasing all outstanding enhancements requests to version 4.0 Moving all open enhancement requests to 4.1 Renaming because changing the return type of an existing method is a breaking change. Adding a new method seems more adequate. In addition there might be a performance penalty involved. Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master. This (and more) has been implemented in bug 353691: org.eclipse.emf.cdo.CDOObject.cdoLockState() org.eclipse.emf.cdo.common.lock.CDOLockState.getLockedObject() org.eclipse.emf.cdo.common.lock.CDOLockState.isLocked(LockType, CDOLockOwner, boolean) org.eclipse.emf.cdo.common.lock.CDOLockState.getReadLockOwners() org.eclipse.emf.cdo.common.lock.CDOLockState.getWriteLockOwner() org.eclipse.emf.cdo.common.lock.CDOLockState.getWriteOptionOwner() *** This bug has been marked as a duplicate of bug 353691 *** Closing |