Re: Refresh the member lock

On 7/29/2011 3:39 PM, David Gibbs wrote:

On 7/29/2011 3:19 PM, Justin Taylor wrote:

IMO, it seems to me to be a simple problem, with an equally simple
solution. RDp is re-opening source members without locking them.
RDp needs to be fixed to relock those source members or open the
member in browse if it cannot get a lock (notifying the user of
course).

Last time I checked (which is about 30 seconds ago), that's exactly what RDp does.

If a member is locked by another editor, it displays a dialog indicating that the member is locked and tells you what job is holding the lock.

You're offered the ability to open the member in browse mode or end the other job and open the member in edit mode (assuming, of course, you have the authority to end the other job).

david

I think the problem arises when you shut down the workbench with open members. When you bring the workbench back up, I believe you are able to edit the source code without locking the member. The lock occurs when you go to save the source code. Theoretically multiple developers could be in that same state (although it would require some specific circumstances) and one developer could update, then the other, and the second update would overwrite the first.

I have a vague memory that Rational checks the source change date when it attempts that secondary lock, and you will indeed get a message saying the member on the host doesn't match the member in your cache, although that is pure supposition. I have not had a chance to actually try it.

Joe