At least with versions of 4D prior to 16, even a READ ONLY will not necessarily release an individual record, local or server. I have ended up making a habit of using LOAD RECORD or UNLOAD RECORD after ending whatever code I am running that edits and saves record(s). The READ ONLY command doesn’t take effect until the selection is refreshed, loading or unloading the record afterwards will guarantee that the record is no longer locked to other processes running anywhere. The same precaution applies to READ WRITE, but I just call that before I retrieve the record I’m working on nearly always, so it’s usually loaded in the correct state as a matter of course.
I find it disconcerting that I can delete any number of records highlighted in an output form, even in READ ONLY mode. JJ > On Dec 5, 2017, at 5:38 PM, [email protected] wrote: > > Message: 1 > Date: Tue, 5 Dec 2017 12:17:02 -0800 > From: Kirk Brooks <[email protected] <mailto:[email protected]>> > To: 4D iNug Technical <[email protected] <mailto:[email protected]>> > Subject: Execute on server gotcha > Message-ID: > <CAHY=XksWWbx5urH=+GjRzkRcGH0sN=0nfjrapydd3tj7kdw...@mail.gmail.com > <mailto:CAHY=XksWWbx5urH=+GjRzkRcGH0sN=0nfjrapydd3tj7kdw...@mail.gmail.com>> > Content-Type: text/plain; charset="UTF-8" > > I use EOS methods a lot. They can make a huge difference since we run over > IP connections. As part of my init for new processes I put all tables into > Read Only and unlock the ones I need as I go along. You all probably do > that too. > > Every now and then I'd be vexed by occasional locked records. 4D reports > them as being locked by a process I know started off with all tables read > only and I couldn't find anyplace where I'd changed it on that particular > table. And the randomness made it hard to replicate - especially on my > development machine. > > This morning I finally realized it was the result of some EOS methods. > Here's the deal (I suspect most of you already know this): > > When a method executes on server it runs in the 'twin' instance of the > process on the server. That's a totally separate memory space. It's a > totally separate record locking space as well. So when I set a process to > READ ONLY(*) this is only true for the client side instance of the process. > The server side twin is still the default of READ WRITE(*). > > I have some EOS methods that do things like complex queries to get arrays > or sums that are optimized on the server. It hadn't occurred to me this is > where I was locking up records sometimes. But it was. Because the twin > process was still locking all the records it touched. > > The solution I implemented is an addition to my process init method. A new > method that executes on the server : > > If (Application type=4D Server) > > READ ONLY(*) > > End if > > I added the test for the application type because calling EOS methods in > single user mode runs in the same process and that could be confusing > sometimes. And in reality I have some more stuff in there but this makes > the point. > > > -- > Kirk Brooks > San Francisco, CA > ======================= ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
