RDi does setup a member lock when open a member (or saving)
What Ken is seeing is that when you reopen RDi after shutting it down. It
loads the members that you had open before, but it does not go to the IBM i
to do this, it simply loads them from the local cache and the lock is not
reestablished. When he saves, this is the first time we are going out to
the IBM i and so now the lock is reestablished.
There is an RFE out there to get RDI to reestablish locks on members when
editors have been left open on shutdown. (Right now we are just following
standard Eclipse behaviour).
From: CRPence <crpbottle@xxxxxxxxx>
To: wdsci-l@xxxxxxxxxxxx
Date: 10/31/2015 10:33 AM
Subject: Re: [WDSCI-L] RDi 9.5 "not responding"
Sent by: "WDSCI-L" <wdsci-l-bounces@xxxxxxxxxxxx>
On 31-Oct-2015 08:30 -0500, Ken Killian wrote:
Gee, I thought RDI & SEU handled member locks...
1.) Open the member in RDI for EDIT
2.) Open the SAME MEMBER in SEU for EDIT
It now allows this???? <shock!>
The SEU first attempts to get an Exclusive-Allow-No-Others (*EXCL)
lock on the member when first loading, then if successful, obtains and
holds an Exclusive-Allow-Readers (*EXCLRD) lock and then drops the
Exclusive lock, while maintaining the *EXCLRD lock while the SEU on that
member persists. Thus any thread that wants to access the data from the
unsaved-changes can obtain a copy; that is why EDTF, CPYSRCF, RDi, or
any other feature just requesting the data can get a copy of that data.
Each feature has the option of doing what SEU does, and prevent all
but exclusive access, but any client editor effecting that requirement
would be quite the deviant.
When I try to save it RDI, I get this message: CPF3156E ("...in use")
presumably correlating with the server msg CPF3156 "File &1 in library
&3 in use."
1.) Close SEU
2.) Save source in RDI
3.) try to reopen source edit mode in SEU, I get this:
EDT0221 - "...in use."
<<SNIP>>
AIUI the RDi holds an *EXCLRD lock like SEU [though I've no idea why
given the concept is anathema for typical client-based editors AFaIK; an
attempt to effect a conceptual difference between that as online-edit vs
typical offline-edit, I suppose], and if so, the msg EDT0221 in that
case would just reflect the inability of the STRSEU request to obtain
that first Exclusive lock. And just a /save/ from the RDi vs the
similar action of a /save and exit/ of the SEU, presumably has the RDi
maintaining the lock, just as SEU would in a Save-with-return-to-edit.
I've no idea what\when RDi would drop their lock, if indeed held as I
understand; what I found in a doc on the web for RSE LPEX editor was
that "Locks released when editor is closed or the RSE connection is
disconnected" but when using iProjects and LPEX editor "No RSE job
needed on IBM i server Member PAYROLL is not locked" [noting that their
example was editing SRCMBR(PAYROLL)] in a document entitled "Rational
Developer for IBM i (RDi) Working offline using i Projects".
--
Regards, Chuck
--
This is the Rational Developer for IBM i / Websphere Development Studio
Client for System i & iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/wdsci-l.
midrange.com
