• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

nx: contractor - max please help

 
Mike Southgate
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Max;
I read in an earlier thread you suggest not using a lock manager and simply use a hashmap in Data. That is what I've done. You've indicated that it needs to be static - why? Would implementing the Data class as a singleton get around this?
And last, my application works fine with the locks except for one thing. When a client asks for a record that's already locked it just hangs there until the lock is released at which point it becomes responsive again. I hae the client locking the record when the user selects the row in the JTable. I'd like to put up some message to the user before this happens, or find another way around this. Suggestions?
ms
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mike,

Originally posted by Mike Southgate:
Max;
I read in an earlier thread you suggest not using a lock manager and simply use a hashmap in Data. That is what I've done. You've indicated that it needs to be static - why? Would implementing the Data class as a singleton get around this?


Yes, using a single instance gets around this. But the point here is that you're differing the problem, you're not really avoiding it. That is, there needs to be central resource, somewhere, that all the clients have (indirect) access to, which tells them that client X has record Y. This can be a LockManager, a single instance of Data, or a single static member variable in data.


And last, my application works fine with the locks except for one thing. When a client asks for a record that's already locked it just hangs there until the lock is released at which point it becomes responsive again. I hae the client locking the record when the user selects the row in the JTable. I'd like to put up some message to the user before this happens, or find another way around this. Suggestions?
ms

yes, I have a suggestion: don't change anything . That's per spec, AFIK. Sun didn't ask you to design a wonderful application here: they asked you to design this one. That is, the point of the SCJD is to demonstrate your mastery of Threads, RMI, etc. Sun doesn't really care about how usable the app is, per se. It's just a metaphor to them. What they're interested is an obvious demonstration, by you, that you can make all this stuff go Zoom. Making one remote client wait because another has the record locked qualifies as such.
All best,
M
[ July 21, 2003: Message edited by: Max Habibi ]
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just to butt in again...
Sun's spec dictates how the lock() method should behave in fairly precise terms However they don't say so much about how the client uses the lock method. If you want to write the client so it's a little more usuable, that's certainly possible without contravening Sun's specs. E.g. you could have the client request a lock in a separate thread from the GUI event handler, and then notify the client somehow when the lock has finally been granted. This may be a little more complex, or a lot more complex, depending on how you set it up. So it's your choice - how easily do you think you can do this, and how important is the usability to you? Personally I like the idea of making the GUI responsive, but Max is right that you don't want to get hung up on this issue. I'd play with the idea a little bit to see if there's a way to get it to work, but "Keep It Simple" is a good mantra to remember here.
 
Mike Southgate
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is there a simple box in swing that you can show, like a dialog except that it doesn't require a user response? If there were I could just show it before I do the lock and then make it invisible when I get the lock number. Something like the JOptionPane except without the buttons...
ms
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
/*
Originally posted by Jim Yingst:
Just to butt in again...


My favorite Buttinsky

Sun's spec dictates how the lock() method should behave in fairly precise terms However they don't say so much about how the client uses the lock method. If you want to write the client so it's a little more usuable, that's certainly possible without contravening Sun's specs. E.g.

Jim is right, of course, that you're free to make the application as robust as you like. However, I suggest that you adhere to the client's explicit requests, and give them a simple app that does what they asked for, without bells and whistles. After all, there's the argument that you're supposed to avoid unnecessary complexity(which providing non requested services would probably fall into). There's also the argument that, ethically, you don't have the right to make your client wait longer for an application because you decided to give them things they didn't ask for.
Put yourself in the grader's shoes for a minute, if you will. I'm sure they're wonderful folks, but really, they want you to make their life easy: in turn, they'll make your life easy. That's just human nature.
If they see that you application works like thousands of other successful applications, then they'll be in a good mood. They'll take a leisurely stroll though your locking and networking code, look for abnormalities, compare your essay exam with what they see, and call it a day.
However, if you make them work harder, they will have had to work harder. That just human nature too. That's not to say you shouldn't treat this as the wonderful learning experience it is, but you should help yourself pass the darn thing.

Personally I like the idea of making the GUI responsive, but Max is right that you don't want to get hung up on this issue. I'd play with the idea a little bit to see if there's a way to get it to work, but "Keep It Simple" is a good mantra to remember here.

Jim's advice is pretty consistent with my own opinion. By all means, dig in. But I think that once you start swimming in the murky depths of multithreading of with Swing, you'll leave it behind quickly. In the meantime, let me know if I can help.
All best,
M
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mike
Is there a simple box in swing that you can show, like a dialog except that it doesn't require a user response? If there were I could just show it before I do the lock and then make it invisible when I get the lock number. Something like the JOptionPane except without the buttons...

So many options to choose from ....
You could just have a status bar at the bottom of your main window, and put a message in there telling your users what you are doing.
Or you could create a custom JOptionPane / JDialog
Or you could create a custom JWindow
Regards, Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic