• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Very Last Question (I promise)

 
Matt DeLacey
Ranch Hand
Posts: 318
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey All:
Many thanks to all who have helped me out here. I'm very grateful for all the expert advice. I just have one last question... and then I just have to do a tiny bit of extra documentation and then submit. Hopefully, I'll submit. OK, so here goes the very last...
I made my server with a GUI and made it so that whoever is managing the server can lock the database (-1 db lock) and unlock it and close it...that's it. Well, it all works fine but if I try to lock the database twice, then the GUI locks up. However, the server isn't locked up it can still service client and requests, and strangely enough the GUI will become unfrozen if you do a -1 db UNLOCK from the client (or just individually release each of the clients). I know Swing is not threadsafe and I don't see that I have tried to do any changes to the GUI from anything other than the event dispatching thread. Does anybody have any ideas about this? I use a Vector to hold locks and just synchronize on the Vector. OK, no mor questions...
With Respect,
Matt DeLacey
 
R Bischof
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Matt,
that behaviour is OK!
You lock the DB, the lock is granted and than you lock it again. The lock method blocks until the lock is granted (as specified).
So the locking thread is block until the lock is released.
The only problem is that you are using the Swing event thread to execute the lock method. So the Swing thread is blocked and cannot update the UI until the lock is granted and the thread is allowed to continue.
The cool solution is to spawn a new thread in your GUI event method. That way your GUI is no longer frozen. The problem is that you still have to wait for your spawned thread to finish before the user may do anything else since you want to know if the lock has worked.
The simpler one is to check for an existing lock before locking the DB. That way deadlocks are still possible but VERY unlikely. Another solution is to provide a new lock method that locks is the lock is available or throws an exception if the lock is already granted.
Rainer
 
Matt DeLacey
Ranch Hand
Posts: 318
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks R:
Your advice is greatly appreciated.
With Respect,
Matt
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic