Memory file conflicts
Started by Mike Nicholson, Sep 06 2006 09:41 AM
21 replies to this topic
#1
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
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
Posted 06 September 2006 - 10:18 AM
Mike
Just tried this on Tru64, 5.5r345. Did not get any problem...
Catch ya,
Cleve
Just tried this on Tru64, 5.5r345. Did not get any problem...
Catch ya,
Cleve
#4
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
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
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
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
#7
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.
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
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
-Rick
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
-Rick
#10
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.
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.
#12 Guest_Old Fart_*
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.
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.
#13
Posted 07 September 2006 - 07:40 AM
Maybe group psychosis?P.S. I have demonstrated this to witnesses so I'm not going mad
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.
of the poster and do not represent those of any organisation.
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users