Re: Refresh the member lock

[Sam_L <lennon_s_j@xxxxxxxxxxx>]

Here’s my take:

The desire is to ensure that two people are not editing the same source 
member concurrently.

If someone is editing the source member in RDP, then RDP needs to have 
an exclusive read lock on the member so that nobody else can change it. 
 This locking occurs automatically, I assume, when RDP opens the member 
from the host.  That lock is lost when you close down RDP.

If the member was opened from the local cache, then as soon as a change 
is made, RDP should do two things in the background:

  1) Reestablish the exclusive read lock;
  2) Check the member timestamp to see if the member was changed 
outside RPD.

Then issue appropriate warnings if there are conflicts.

It seems to me to be much more useful to check for conflicts at the time 
you make your first change, rather than making changes for an hour and 
finding at save time that the source had changed on the host.

You can defer these checks until an actual change is made, so you could 
be editing for a few seconds before you receive a warning, but Ctrl-Z 
would be your friend.  A round trip to the host to accomplish locking 
and timestamp checking should, I imagine, take less than 5 seconds in 
most cases.

Of course, does this problem occur often enough to enough people to 
justify an enhancement, or prioritizing an enhancement about the others 
that are out there?  (I think it could be worked around in most cases 
with separate libraries and/or a source control system, but I don’t work 
in your shop, so it’s just my opinion.)

Sam


On 7/28/2011 3:55 PM, Edmund Reinhardt wrote:
> I have checked with development and this would be a candidate for an RFE
>
> Currently, when the user tries to save in the new RDP session, we compare
> the last-updated timestamp and put up the 'Save Conflict' dialog prompting
> them what to do.
>
> We could explore the possibility of adding function to check the host
> timestamp when RDP is started  (or if they type changes in the file ?  or
> bring the file edit session into focus ... ) and then either put a new lock
> on the file, or go into the Save Conflict prompt ...  ( or a modified
> version of it)
> Might even be cool to offer a new option to show them the differences
> between theirs and host version   .. them let them decide ...
>
> To ignore the cache and always open from the host would slow down the
> reopening of RDp considerably by having to download all the files, also the
> developer would not be made aware of any changes made since the last time
> they edited.  The solution above would defer the cost of communication
> until it was necessary.
>
> Regards,
>
>
>
> Edmund (E.H.) Reinhardt
> COBOL IDE on AIX, DDS, WebFacing, System i Application Development,
> Rational Developer for Power