• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Locking in Standalone mode..

 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi guys,

Just a quick question really. Did anyone implement a seperate version of their Database class (or whatever you've called it) which doesn't implement locking, for use in standalone mode? I was thinking, would it be worth the extra overhead locking when there is only going to be one thread accessing the database, or would the overhead be negligible?

This might be a daft question, sorry if it is!

Cheers
 
Bartender
Posts: 2292
3
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey, Mark!

In fact, this is a very good question. The answer is: your locking mechanism must work on both standalone and networked mode. Even though you'll just have one thread in standalone, you must implement the locking mechanism for that as well.
 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It will be stupid to have separate code for the database when you already coded it for multi-user environment. If I were to evaluate such assignment, I would deduct points for such design.
 
Bartender
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Roberto is right. Your locking mechanism should work for local and remote modes. If it handles multithreading correctly in the remote mode, it will definitely work for the local mode because local mode is saying having only 1 user in the remote mode.
 
Mark Barrett
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for clearing that up for me Roberto.

Vasya Pupkin wrote:It will be stupid to have separate code for the database when you already coded it for multi-user environment.



Depending on how it was designed, there wouldn't need to be a separate implementation of the database class. The decorator design pattern could be used for example. One class, the Database class would do all the general database stuff, then a 'decorator class', called ConcurrentDatabase, would implement the locking mechanism before calling the corresponding method on the Database class. eg:



Obviously this would require that there already be an instance of DatabaseImpl to give to ConcurrentDatabaseImpl, but this would allow you to swap in any locking implementation at runtime or locking could be disabled altogether at runtime.

I guess there isn't much between this method and using a façade to call locking procedures. Unless anyone can give me a good reason why this would be a bad design..?
reply
    Bookmark Topic Watch Topic
  • New Topic