Hi friends, The operation order of my doBooking(int recNum): 1.read-->2.lock-->3.read-->4.modify-->5.writer--> 6.unlock The doBooking() method is in the client. Supposing like that: Client A wanted to doBooking(record=3),A found there were enough seats and no one had the lock(step 1).So A got it and ensured whether there were still enough seats again(step 3).When A wanted to modify it,something happened that A'mouse was crashed. After 10 min ,System receive A's lock. Now A's mouse is ok and comes back. The problem occured,A still could modify any record because A had got it just now. How to prevent such things? Need the method like modify() check the object has the lock? Thanks!!!
After 10 min ,System receive A's lock I'm not sure I understand here - does A's lock expire after 10 minutes, so now others can acquire it? (I don't see any requirement like this in my assignment (NX-Contractors), though it's a good idea - does another version of the exam require it?) If you're implementing anything that allows a lock to time out like this, you have to make sure that A gets a SecurityException (or whatever the equivalent is for your assignment) when they try to use the lock after it's timed out. If your locking mechanism involves "cookies" (as does NX-Contractors) then just change the expected cookie value when you time out the lock. When A tries to modify something later, he'll still be using the old cookie value, so the method will throw a SecurityException. For those of us doing NX-Contractors - has anyone implemented a lock timeout as suggested above? Seems like a nice idea, but my gut feeling is that it's on the borderline between being necessary for a well-designed system, and being too much added complexity beyound the stated requirements. Thoughts, anyone? [ May 20, 2003: Message edited by: Jim Yingst ]
I'm not sure I understand here - does A's lock expire after 10 minutes, so now others can acquire it? Ray may be referring to the implementation of the Unreferenced interface on the server, although the scenario he pointed out would not trigger unreferenced() because there would still be a reachable reference to A's remote object. "A" would hold the lock forever unless a timer was used to release the lock at some interval. Even if unreferenced() were called, which should release the lock, the lock owner should be checked before modifying a record anyway. So Ray's scenario should be impossible with the proper safeguards on the server. For those of us doing NX-Contractors - has anyone implemented a lock timeout as suggested above? Seems like a nice idea, but my gut feeling is that it's on the borderline between being necessary for a well-designed system, and being too much added complexity beyound the stated requirements. Thoughts, anyone? I did the Fly by Night and decided against using a lock timeout because I used a lock on demand scheme. Now if you are using client-active locking, that is, the client automatically locks a record when the row in your table that corresponds with the record is selected by the user, then I believe that it would be necessary to provide a lock timer because a user could select a record and go out for a long lunch leaving the record in an unmodifiable state.
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Joined: Jan 30, 2000
Interesting. I believe I can use lock-on-demand, because the only updates that the GUI needs to be able to make are ov a single field (customer ID of the person who "booked" a record) - and this is not an allowed operation if the record is currently booked by someone else. So, a client can look at all the records they want, without locking anything. Then when they want to book one (apparently not yet booked by anyone else), the system can lock -> read -> check if still unbooked -> book record (update) -> unlock as one uninterrupted operation. If the record turns out to have been booked by someone else after the last read, this becomes lock -> read -> check if still unbooked -> unlock (no update) -> tell user "bite me, you're too late" This works if you're only allowed to update a blank field (which is true for customer ID). But if the GUI were to allow more general updates, then you really need to force the user to lock a record and look at the most recent version of the record before they change it - else the user just ignores someone else's changes entirely, defeating the whole point of havning a locking mechanism. So yes, a timeout mechanism would seem necessary here. Or at least, the ability to add this in the future (when the GUI provides fuller update functionality) is necessary. Hmmm... I think I can justify omitting it now, since nothing about timeout is mentioned in the specs. (The specs do mention that the Data class needs an update() and delete() method, even though the GUI won't (yet) need to call them - so I see more justification for making update() and delete() actually work, while a timeout is more of an optional thing that hasn't quite been asked for yet. But maybe I'll put one in anyway, to be safe... Note that I use "booked" in quotes above because it seems to be a nonsensical term in the context of NX-Contractor. You wouldn't book a contractor, not without recording the dates he's booked for (which are not present in the Contractor database). I'm thinking it sounds suspiciously like part of the text for a hotel room reservation system, or a flight reservation system, and someone at Sun was careless in re-using text from another assignment when they cooked this one up. Unless I'm missing something, which is always possible... [ May 20, 2003: Message edited by: Jim Yingst ]
Hi Jim, You said: and someone at Sun was careless in re-using text from another assignment when they cooked this one up Had to laugh at that. I have been working on flight reservation systems for the last 5 years (with some hotel and car reservations thrown in for good measure), and one of my biggest problems with doing the Fly By Night Services assignment has been stoping myself from adding what I consider to be essential functionality. I think Sun have worked out their solution first (client app, networking, and server solution) and then have tried to force that solution into different scenarios (flights, hotels, contractors). Since they have a solution in mind already, they have not tailored the requirements to the particular assignment. Back to topic: I also like the idea of a timeout. It was one thing that annoyed me with the FBNS assignment: in that it was explicit that all calls to lock would block until the lock was achieved. Regards, Andrew