• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Locking in Standalone mode..

 
Mark Barrett
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • 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
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • 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.
 
Vasya Pupkin
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • 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.
 
K. Tsang
Bartender
Posts: 3585
16
Android Java
  • Mark post as helpful
  • send pies
  • 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
  • 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..?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic