This week's giveaway is in the JDBC forum.
We're giving away four copies of Java Database Connections & Transactions (e-book only) and have Marco Behler on-line!
See this thread for details.
Win a copy of Java Database Connections & Transactions (e-book only) this week in the JDBC 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 ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Knute Snortum
  • Paul Clapham
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Frits Walraven
Bartenders:
  • Ganesh Patekar
  • Tim Holloway
  • salvin francis

Question regarding the singleton data and synchronized method approach  RSS feed

 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

I agree that the simplest (but not most effective) solution is to make sure that the data access methods are synchronized on the same object, and doing that is easiest by ensuring that the data class is a singleton.

I have synchronized all methods in my data singleton class except for two, lock and unlock, because concurrent work simply did not work when update and lock (for different clients) were synchronized on the same object.

The data class methods lock and unlock use an underlying class LockManager (holding the lock map), and I chose then to synchronize the methods lock and unlock in LockManager instead of in Data. So locking will synchronize on another object.

Now I'm wondering...will this really be safe? ..since the LockManager class is not a singleton. I believe it should, since the only reference to LockManager is inside Data, which is a singleton. The LockManager object is initialized only once, when Data is initialized.

Does this approach seem ok?
 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mikael,

Now I'm wondering...will this really be safe? ..since the LockManager class is not a singleton. I believe it should, since the only reference to LockManager is inside Data, which is a singleton. The LockManager object is initialized only once, when Data is initialized.



I would go a step further myself and declare the LockManager with default access so that it is only visible from the package your Data class is in. Essentially, your design is still gearing towards instantiating the LockManager once and it just seems logical to me to make it a Singleton as well. I don't believe there is anything wrong with your approach, but you should test the locking mechanism thoroughly.

I only method synchronized create() and find() methods, while all the others were block synchronized, and it was all implemented in the Data class and I managed to provide concurrent record access to my database structure.

Cheers,

Vlad
 
Bartender
Posts: 2292
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Howdy, y'all.

Mikael, even though your LockManager class does not explicitly implement the Singleton pattern, there's certainly just one instance of it in the entire application, since the object's life cycle is controlled by a Singleton object. So synchronizing its methods is safe too. But, just for the sake of security, run these tests on your Data class.

Vlad Djordan wrote:I would go a step further myself and declare the LockManager with default access so that it is only visible from the package your Data class is in.



Good call! It is a good way to protect your API.
 
The moustache of a titan! The ad of a flea:
how do I do my own kindle-like thing - without amazon
https://coderanch.com/t/711421/engineering/kindle-amazon
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!