Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

NX: hooks and DB locks

Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello, my dear Ranchers,
Currently I am doing nothing in my project to prevent data corruption arising from the server closing down with networked clients still attached. I have a server GUI, so when the close option is taken, I start the close down operation.
My first question is, should I take action by specifying a ShutdownHook or just continue the close down operation in the current thread? I assume that a ShutdownHook caters for situations in which an application ends in a controlled or uncontrolled manner, so my instinct is to use the Hook.
Secondly, I am thinking of locking the database as part of the shutdown procedure. The idea is that by the time I have locked all the records, I can be sure that no client is in the middle of an update. My concern is whether this processing, if running in a separate thread as part of the hook, will finish before the connection exception is issued to the client. Will a hook help? That is, will it ensure the lock process completes before the network goes down?
Any thoughts on this will be appreciated.
author and jackaroo
Posts: 12199
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Simon,
The earlier assignments (Fly By Night Services) did not require a GUI on the server, and many people who have worked with server side applications dislike having GUIs (I can give reasons if you like), so they used the shutdown hook to allow a clean way for the server application to shut down.
However since you are required to have a GUI, the shutdown hook is not as relevant - you can do the shutdown from the GUI itself.
Where the shutdown hook will still benefit those with GUIs, is that the server operating system can then initiate a shutdown of your server application - it does not need manual intervention (for example, doing a clean shutdown if power goes out (requiring signalling from the UPS)). I would consider this a necessity in a real server application.
But this is going a bit beyond the requirements of the assignment. You do not need to worry about how to handle such problems in this assignment, and you will not get extra marks for doing so. (If you do want to explore this, though, this project can be a nice place for you to experiment).
If you did have both the GUI shutdown option, and a shutdown hook, then I would recommend you take care to ensure that you do not have two bits of code calling the shutdown routines simultaneously (my preferred option would be to have the GUI just exit, leaving the shutdown hook to do the real work - this would have to be well documented though).
Rather than locking all the individual records, you might want to just set a flag to say that shutdown is proceeding, and refuse to grant any more locks and/or do any more writes while that flag is set. Then as soon as you know that there are no more writes currently in progress, you can shut down. This means that you could shut down while locks are still granted, but you know that the database is in a clean state.
Going back to my example of the UPS trying to shut down your application - in this case, you only have a limited time to do clean up operations before the UPS runs out of power. So you do not want to be waiting while trying to get all the individual locks. The sooner you know you can safely shut down the better.
And even if a client owns a lock, and issues the write request between the time that you started the shutdown and the time you have completed the shutdown, it still wont matter: the flag will have stopped the update of the file (so your data file is intact), and your client will (eventually) get an exception, so they will know that their booking did not succeed.
Regards, Andrew
Simon Ingram
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Andrew,
You have clarified the issues in your usual lucid style!
That's a very big dog. I think I want to go home now and hug this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic