NX Contractors 2.1.1: Lock persistence

[Paul Tongyoo]

Is a client's lock supposed to stay persistent between invocations?
Thanks,
Paul (...al-...most....do-....ne..... )

[Philippe Maquet]

Hi Paul,

Is a client's lock supposed to stay persistent between invocations?

What do you mean exactly by "persitent" in this context ?
Best,
Phil.

[Jim Yingst]

Alternately, what do you mean by "invocations"? If you're talking about different method invocations during a single run of the program, then I'd say that yes, a lock() should affect a record until unlock() is called. If you're talking about invocations of the program, i.e. what happens if the program exits and is restarted later - then I'd say no, the program doesn't have to try to save the information about locked records. Sopping and restarting your server will effectively unlock all locked records. However, your instructions may be different from mine. Take a look at the DB file format - is there any way for you to indicate in the file that a record is locked? If there is, I'd say yes you should update the file when a record is locked, and this will provide persistence. If not, then you would have to create some alternate persistence structure, separate from the file, and that seems like too much work for something that's not clearly required. Plus in my instructions, it's mentioned that there are other programs that could manipulate the DB file while my program isn't running. These other programs would not know anything about your persistence functionaility, and would not respect it. So I would assume that the idea of "locked" vs. "unlocekd" records becomes meaningless once the program exits - all locks are forgotten. But again, check your own instructions to see if these ideas make sense.

[Paul Tongyoo]

Originally posted by Jim Yingst:
... If you're talking about invocations of the program, i.e. what happens if the program exits and is restarted later ....

Phil/Jim -- Thank you for your responses and apologies for the vague wording of my question. I am unsure if a client's lock should be persistent (remain actively locking a particular record) between invocations of the client-side program (not the server).
The question arose when thinking about the situations when the delete operation would throw a SecurityException; it says the delete option would prevent deletion of a record if the calling client does not pass the same cookie that originally locked the record. This spec brings up two questions about lock persistency:
1) If the lock isn't persistent, won't any malicious client be able to delete the record after the "locking client" unlocks the record after a lock-(read_check)-update-unlock operation, and
2) Does this scenario bring up the neccessity to allow a client (the actual user?) to explicitly lock or unlock a record so that it remains secure (not updated upon or deleted)?
The functionality in (2) seems way out of the specified scope but makes sense to me -- which is a hint that I must be missing some important issue here about the requirements of the locking mechanism.
Paul
P.S. btw, Jim - no my data file doesn't include a field to indicate a record's lock status.

[Jim Yingst]

1) If the lock isn't persistent, won't any malicious client be able to delete the record after the "locking client" unlocks the record after a lock-(read_check)-update-unlock operation,
Yes. But what does this have to do with persistence? After one clinet unlocks a record, another can then lock it and do whatever they want to it. The system isn't designed to protect against malicious clients, especially not when a record is unlocked; it's designed to provide for protection while a record is locked to allow a client to complete a sequence of related actions (e.g. read and then update) without being interrupted by another client.
2) Does this scenario bring up the neccessity to allow a client (the actual user?) to explicitly lock or unlock a record so that it remains secure (not updated upon or deleted)?
You mean, allow a client to lock a record and never unlock it? Well, that seems to be possible in the API I have, but why would you ever want to write a client that does this? Look at what your client GUI is expected to actually do in this assignment - book a record. Is there any reason to leave a record locked after it's been booked? I'm not sure what you're thinking of here, but I suspect it's outside the scope of the assignment.

[Paul Tongyoo]

Originally posted by Jim Yingst:
... I'm not sure what you're thinking of here, but I suspect it's outside the scope of the assignment.

Yes - your answer has brought me to the conclusion that my interpretation of the locking mechanism has been beyond the scope of its specification by Sun. Thanks for the clarification!
Paul

[ November 04, 2003: Message edited by: Paul Tongyoo ]

[Lukasz Racon]

Quote:
"""
You mean, allow a client to lock a record and never unlock it? Well, that seems to be possible in the API I have, but why would you ever want to write a client that does this? Look at what your client GUI is expected to actually do in this assignment - book a record. Is there any reason to leave a record locked after it's been booked? I'm not sure what you're thinking of here, but I suspect it's outside the scope of the assignment.
"""