Jump to content


Photo

Memory file conflicts


21 replies to this topic

#1 Mike Nicholson

Mike Nicholson

    Expert

  • Members
  • PipPipPipPip
  • 196 posts
  • Gender:Male
  • Location:Stockholm, Sweden

Posted 06 September 2006 - 09:41 AM

I've found an interesting bug in memory file usage.

For info, wer're on 5.5 r308, running on VMS

To reproduce:

1. Create a memory file and a simple screen function for maintaining it.

2. Add a record in one screen but leave the screen in the record (i.e. don't commit the add)

3. Lookup the same record in another session - so far so good, it doesn't exist.

4. Now try and add the same record in the other session - you'll get an error saying it already exists.

5. Finish adding the record in the original session. Now you can add the same record in the other session.

I've logged on & off, tried it with another user - still get the same results.

It's made me a little wary now about using memory files - something I'd previously believed to be pretty stable.

Cheers

Mike

#2 Cleve Haynes

Cleve Haynes

    Expert

  • Members
  • PipPipPipPip
  • 172 posts
  • Gender:Male

Posted 06 September 2006 - 10:18 AM

Mike

Just tried this on Tru64, 5.5r345. Did not get any problem...

Catch ya,

Cleve

#3 Mike Nicholson

Mike Nicholson

    Expert

  • Members
  • PipPipPipPip
  • 196 posts
  • Gender:Male
  • Location:Stockholm, Sweden

Posted 06 September 2006 - 10:25 AM

I had a little bet with myself whether it would be you or Rob that replied to this one first.

As it turns out I lost ;-)

Interesting, wonder if it's a version thing or a platform thing.

Cheers

Mike

#4 Rick Young

Rick Young

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 265 posts
  • Gender:Male
  • Location:Guelph, Canada

Posted 06 September 2006 - 01:34 PM

5.5r517 on HP-UX - if I understand correctly, the MKY file is "hidden keyed" by @TERM.

As such, on two screens, I can add apparently the same record (with no error).

Just to ensure a valid test, here's what I did:

@F shows

CO- AUTO EXTERNAL FILE KEY RECORD
DIV SEQUENCED RECORD FORMAT TYPE LENGTH LENGTH
FILE NAME: TEST2 Y MKY 6 10

DATA MAX FILL SPECIAL ARRAY
SEQ TYPE VARIABLE NAME LEN CODE DISPLAY-CODE CHECK SIZE
--- ---- -------------------------------- --- ---- ------------ -------- -----
001 K TEST_ONE 3
002 A TEST_TWO 3




On two different screens, I then added the values TEST_ONE = "1 " and TEST_TWO = "ONE".

Both added and read without error.

HTH
Rick

Edited typo in revision

Edited by Rick Young, 06 September 2006 - 01:35 PM.


#5 Mike Nicholson

Mike Nicholson

    Expert

  • Members
  • PipPipPipPip
  • 196 posts
  • Gender:Male
  • Location:Stockholm, Sweden

Posted 06 September 2006 - 01:43 PM

As I understand it @TERM doesn't enter into it - it's a session dependant memory space.

In case I'm wrong though I definitely had different sessions, with different users and had logged both in and out a couple of times just to make sure.

The sequence

1. Add record in one session
2. Add record in second session

produces no error

The sequence

1. Start to add a record in the first session and get past the read field
2. Try to add a record in the second session

does produce the error as described. So it's not that the actual records in the files that are the problem - it's while a record is still being added that it will conflict with another session.

So with your test in session one add TEST_ONE = '1' and sit on the TEST_TWO field, then go to the other session and try and add the same record. What happens?

Cheers

Mike

#6 Mike Nicholson

Mike Nicholson

    Expert

  • Members
  • PipPipPipPip
  • 196 posts
  • Gender:Male
  • Location:Stockholm, Sweden

Posted 06 September 2006 - 01:44 PM

P.S. I have demonstrated this to witnesses so I'm not going mad :D

#7 Rob Donovan

Rob Donovan

    rob@proivrc.com

  • Admin
  • 1,640 posts
  • Gender:Male
  • Location:Spain

Posted 06 September 2006 - 01:47 PM

Hi,

I presume its some bug with shared memory.

When you add a record into a ProISAM file, and have not yet commited, its added into shared memory as a lock, so that a record locked messasge can be displayed if someone else tries to add the same record.

I presume, that since Memory files are based around ProISAM files, that on some platforms or conditions, the kernel is not ignoring the lock table for Memory files....

Rob.

#8 Rick Young

Rick Young

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 265 posts
  • Gender:Male
  • Location:Guelph, Canada

Posted 06 September 2006 - 01:49 PM

yeah - that's how I did it - - screen one sitting on TEST_TWO field, then entered the record in screen 2, then went back to screen one and completed the entry. So, I guess that they've fixed the issue by rev5.1.7

With regards @TERM, I didn't really mean to state it so specifically - I just interpret the equivalent behaviour of how I understood them to work :D


-Rick

#9 Mike Nicholson

Mike Nicholson

    Expert

  • Members
  • PipPipPipPip
  • 196 posts
  • Gender:Male
  • Location:Stockholm, Sweden

Posted 06 September 2006 - 02:02 PM

I suspect, based on Rob's assessment, that the problem is platform specific rather than version specific.

Not so much I can do about it but still a bit worrying ...

#10 Rob Donovan

Rob Donovan

    rob@proivrc.com

  • Admin
  • 1,640 posts
  • Gender:Male
  • Location:Spain

Posted 06 September 2006 - 03:36 PM

Mike,

As a work around for you, just make sure all your Memory workfiles have @TERM as the first key...

Not the best solution, but it should work...

Rob.

#11 Mike Nicholson

Mike Nicholson

    Expert

  • Members
  • PipPipPipPip
  • 196 posts
  • Gender:Male
  • Location:Stockholm, Sweden

Posted 06 September 2006 - 03:53 PM

Yep, that's pretty much what I'd decided on ...

Kind of defeats the object though ;-)

#12 Guest_Old Fart_*

Guest_Old Fart_*
  • Guests

Posted 07 September 2006 - 07:39 AM

Dear Mike,

I'd bet a small sum that this is a piece of stupidity where ProIV are simulating record locking in add mode for a file type that doesn't support it (eg. RMS) and forgetting that should not apply for memory files.

Yours faithfully from the other side of the room. :D

#13 Chris Mackenzie

Chris Mackenzie

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 368 posts
  • Gender:Male
  • Location:Bristol, United Kingdom

Posted 07 September 2006 - 07:40 AM

P.S. I have demonstrated this to witnesses so I'm not going mad :D

Maybe group psychosis?

Anyway, I've tested on solaris 5.9 & windows server 2003 both
ok.
The content and views expressed in this message are those
of the poster and do not represent those of any organisation.

#14 Guest_Old Fart_*

Guest_Old Fart_*
  • Guests

Posted 07 September 2006 - 07:47 AM

PS.
As far as temporary workarounds go:
Remember background processes do not have a unique @TERM.
If my guess is right then ALIASING the memfile to somethign process specific should work too.

:D :eek:

#15 Mike Nicholson

Mike Nicholson

    Expert

  • Members
  • PipPipPipPip
  • 196 posts
  • Gender:Male
  • Location:Stockholm, Sweden

Posted 07 September 2006 - 08:17 AM

Old fart (what do your friends call you ?? :D )

I'm confused. How would I ALIAS a file that doesn't have a physical counterpart?

And the process isn't background - it's just a simple screen.



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users