• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Liutauras Vilda
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Devaka Cooray
  • Paul Clapham
Saloon Keepers:
  • Scott Selikoff
  • Tim Holloway
  • Piet Souris
  • Mikalai Zaikin
  • Frits Walraven
Bartenders:
  • Stephan van Hulst
  • Carey Brown

private volatile boolean closed; // you got a better idea?

 
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi!
I know that closing the database is an old issue, but it seems I made things
hard for myself (no singletons, many Data instances can share the same database file, etc etc). It seems I have to choose between all bad ways of shutting down.
Bear with me and read a few of them, and tell me what you think. Am I just being paranoid?
  • The globalized option: Keep a global list of stuff to cleanup upon server shutdown. Call a method that cleans it up prior to a System.exit. Perhaps add a VM shutdown hook that does the same. My qualms about it:

  • 1) Asides from the global list, it implies I must either make a global shutdown method or rely on a shutdown hook. Aren't globals supposed to be bad?
    2) It prevents garbage collection.
  • The garbage option: Like the globalized option, but integrated with the garbage collector. The global cleanup list now consists of weak references so garbage collection is not hindered, and the class which holds the open database file gets to close it in its finalize method. The global shutdown method (or shutdown hook) still exists - but now it may have less to do because some cleanup has already been performed. My qualms about it:

  • A) I am afraid junior programmers have lost their way by now.
    B) I am afraid I am overdoing it.
  • The localized option: The database service offers a close method, and delegates that call to the data class, which delegates it onwards until the file is eventually closed. My qualms about it:

  • I) Since in my design, many Data instances can share the same file, I end up having the Data class effectively maintaining a count of how many clients are using the file - that is, in some sense, doing the garbage collector's work.
    II) To avoid unpredicable errors, every method in e.g. the Data class has to check that the close method has not been called (or does it?). Furthermore, these checks must be thread safe (or must they?) - I guess you can boil it down to a "private volatile boolean closed", but still, isn't there a better way?
  • The ignorant option: Assume that the runtime will somehow manage things for you. Or be a bit more careful: Open the file in "rws" mode and close it in the finalizer and assume that takes care of the problem. My qualms about it:

  • #) So far, I haven't managed to find documentation that guarantees this approach will work.
  • The smelly option: When the file-holding object is created, add a shutdown hook that will close the file. If the finalize method of the file-holding object is called, close the file there and remove the hook. My qualms about it:

  • X) Hmm, it just has a bad smell - I have never before heard of anyone who has had to use shutdown hooks.

    Thanks in advance!
    [ March 30, 2004: Message edited by: Nicky Bodentien ]
    [ March 30, 2004: Message edited by: Nicky Bodentien ]
    [ March 30, 2004: Message edited by: Nicky Bodentien ]
     
    ranger
    Posts: 17347
    11
    Mac IntelliJ IDE Spring
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    one word. Refactor.
    Why go through all this trouble when you should just make one instance of the Data class, and all clients have a reference to this one Data class through a Facade. (No Singleton, this is overdone and not necessary)
    Putting in all this "flexibility", that you did, made it unflexible, and more difficult to code, read, maintain, and enhance. Do you think a junior developer will be able to do these tasks?
    There are plenty of posts in this forum that have this kind of design, and it really won't take much work on your part to change.
    I highly, highly, suggest this.
    Mark
    [ March 31, 2004: Message edited by: Mark Spritzler ]
     
    Mogens Nidding
    Ranch Hand
    Posts: 77
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    The reason I have many Data instances is that the lock method in my DBMain interface says something like "locks a record so that it can only be updated or deleted by this client". And with no locking cookies, the only implementation I can think is to associate a client identity with each Data instance.
    Are you suggesting that I should just let my multiple Data instances forward all calls to a singleton that handles the (single) database file?
    Or are you saying I need not interpret the "only be updated by this client" part so strictly and drop having multiple data instances?
     
    Hey, I'm supposed to be the guide! Wait up! No fair! You have the tiny ad!
    Smokeless wood heat with a rocket mass heater
    https://woodheat.net
    reply
      Bookmark Topic Watch Topic
    • New Topic