lock/unlock signatures...

scott irwin

Ranch Hand

Posts: 87

posted 16 years ago

I've been working on my locking today and took a leap that my design could change the signatures of these methods. Anybody else done the same and passed? I'm assuming this comes under the 'imperfect' requirements catagory.

Subha Ambigapathy

Greenhorn

Posts: 18

posted 16 years ago

As long as you have confident of your changes I don't think sun will have any problem. Don't forget to document your choice. What's your Design?? Subha

scott irwin

Ranch Hand

Posts: 87

posted 16 years ago

Basically we have a logical optimistic lock on the row/table. I've seen some posts having problems with keeping the gui active for long locks. Wrong! You don't lock for long periods of time. You lock, do your update and unlock. Because we are not dealing with a transaction monitor here, I've gone with 'optimistic leased locks'. Works like a champ! Now I'm working on the RMI portion and looking at the jdk 1.2 Activation pattern.

Subha Ambigapathy

Greenhorn

Posts: 18

posted 16 years ago

So do you say that client1 and client2 got the same record to read and after that client2 decides to reserve seat. Client2 will modify the data but still client1 got the same old information. Is this OK??

scott irwin

Ranch Hand

Posts: 87

posted 16 years ago

The requirements state that we do not have to update views of other users after we have updated the data. This is the optimistic lock, where it is unlikely that somebody will modify a record while you see it. When they want to reserve a seat, we lock to row, read the record and determine if the requested seat amount is still available. If so, decreament and unlock. If not, unlock and inform user we are sold out (I would also refresh the user's view). With optimistic locking, you usually get some type of stamp indicating the version of the row. Then when you go to update the row, you compare the stamp you got with the stamp that is there. If they are different, you need to either resolve that it is still okay to proceed (in our case we still have enough seats) or inform the user something has changed.

Subha Ambigapathy

Greenhorn

Posts: 18

posted 16 years ago

Sorry for my late reply. Yeah it make sense. But still I am thinking is there any way to implement that the latest changes to update all the clients. Right now I don't have any plan in my mind. Do you need client Id for anything? How did you get the client ID? For what are you using this client ID. Are you using Vector or Hashtable Write me something about your local mode. What's your plan for deploying the classes. This weekend only I am planning to work on lock/unlock logic. Will let you know by monday. Thanks for sharing your idea. Subha

scott irwin

Ranch Hand

Posts: 87

posted 16 years ago

Subha, Don't go down that road! You could implement the Observer pattern in our little database but you are asking for trouble. In the real world, you might use JMS to create a Topic and Subscribe to the Topic. You would then receive events about the Topic, which could be updates. The poor man's version is the Observer pattern where clients register remote objects into the server. The server must hold this list and associate it with objects of interest. When updates occur, the server looks for any registered Observers and issues the call back to the client through the Observer (which was created by client and given to server). While slick, this is way out of scope for our little project (this ain't no real-time space shuttle application!) As far as the details of my implementation, that is left as an exercise to the reader But you get the jist.

tony_lsg

Greenhorn

Posts: 2

posted 16 years ago

Can you show me the detailed implements for lock and unlock? I just got the assignment,I have not any idea about these two methods.

Originally posted by scott irwin:I've been working on my locking today and took a leap that my design could change the signatures of these methods. Anybody else done the same and passed? I'm assuming this comes under the 'imperfect' requirements catagory.