Bugzilla – Full Text Bug Listing
| Summary: | Disambiguate CDOView.enableDurableLocking(boolean) | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Matthieu Helleboid <matthieu.helleboid> |
| Component: | cdo.core | Assignee: | Eike Stepper <stepper> |
| Status: | CLOSED FIXED | QA Contact: | Eike Stepper <stepper> |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | caspar_d, saulius.tvarijonas |
| Version: | 4.1 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | Power to the People | ||
|
Description
Matthieu Helleboid
IDurableLockingManager is only responsible for dealing with the persistent aspect of locks, see the JavaDoc, so the current implementation of #deleteLockArea is correct insofar as it does (only) what the API says it should do. This method is meant to allow the persistent representation to be removed, without necessarily releasing the in-memory locks. That is, it is invoked when the user calls CDOView.enableDurableLocking(false). To delete the in-memory locks, just call CDOView.unlockObjects(). CDOView.unlockObjects() works just fine, Thanks a lot. Sorry, I'm have been misled by some previous discussions about this. I'll deprecate the existing method and add these two:
public String enableDurableLocking();
public void disableDurableLocking(boolean releaseLocks);
commit 61519d15b81df73cbe362efe4c02b924a6992acc Author: Eike Stepper <stepper@esc-net.de> 2011-12-08 08:39:19 Committer: Eike Stepper <stepper@esc-net.de> 2011-12-08 08:39:19 Parent: 821aa1db96646007b7d8a43c4bf3143e6c804867 (Fixed NPE in titlesetter) Branches: master [365719] Disambiguate CDOView.enableDurableLocking(boolean) https://bugs.eclipse.org/bugs/show_bug.cgi?id=365719 Eike, These API changes will be helpful, Thanks. But I think our initial need wasn't really clear. What we needed to do was to delete a lockArea and unlock all the associated objects from another CDO client (later called S). Let's say client A has made local modifications through pushTransaction and have locks on some objects. But for some reasons, he has lost his session and will never reconnect using this lockArea and be able to unlock objects by himself. For that we have another special client S, which is able to delete this lock area and also unlock all the associated objects. For that we had to reopen the transaction using the durableLockingId on client S (which is in fact "embedded" in the server) to unlock objects. If the lockArea deletion was able to also delete the in-memory locks, client S would be useless. But so far, we have implement client S, and so it's ok for us. (In reply to comment #5) > But I think our initial need wasn't really clear. What we needed to do was to > delete a lockArea and unlock all the associated objects from another CDO client Now I'm confused. That sounds exactly like what the releaseLocks parameter on the new disableDurableLocking() method is intended for. In fact you do not need to have a session (client S) to have access to a IDurableLockingManager and use IDurableLockingManager.deleteLockArea(). But in our usecase, with the fact that IDurableLockingManager only delete persistent representation of a lock area, we either need a server restart or a client S to open a transaction to unlock objects. So you're complaining that the server's lock manager holds on the locks? I thought it was about a client initiated issue. Investigating... Sorry, I've misinterpreted this original bugzilla, fixed a different one and resolved this bugzilla. Can you be so kind to open a new one? Closing. |