aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Singleton or Not? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Singleton or Not?" Watch "Singleton or Not?" New topic
Author

Singleton or Not?

Chris Bicnal
Ranch Hand

Joined: Aug 17, 2005
Posts: 80
    
    1
Hi everyone,

Apologies for flaming the forum today but I'm trying to get my project finished this week!

Anyway, I'm in the wrap up stages and have just had a nasty thought about my implementation. I'm working on B&S 2.2.1 and, to cut a long story short, have implemented my Data class as a singleton. Within this class I have a private RandomAccessFile object that represents the data file.

Now, my locking logic isn't based on synchronising each method (as I think a lot of yours are) but on synchronising the RandomAccessFile and a HashMap that I use to map which record is locked.

I've been going through my code today and am trying to think about how I will justify my design on the written exam. Although I'm thinking to myself, why wouldn't I synchronise on each method? I currently have occasions where I have to obtain two locks (which we all know can be risky) although synchronising on each method seems heavy handed to me.

Also, if I synchronise on each method would I still need to make my Data class a singleton?

I thought I had this sorted, but I think I've confused myself by thinking about it too much!

Thanks!

Chris
Fernando Franzini
Ranch Hand

Joined: Jan 09, 2009
Posts: 486
    
    2

Hi Chris
Also, if I synchronise on each method would I still need to make my Data class a singleton?

Of course my friend, cause synchronized methods just work with the same object instance !! And singleton pattern is an elegant way assure that !

About lock strategy I think there is 2 basic way to follow :
1. Syncronized the methods of your class: work well, easy and have some performance issues, cause all object are block.
2. Dont synchronized the methods and use java.util.concurrent.locks inside them: complexy but you can control read e writte locks offering some improve performance related read concurrents acess.

Regards


Fernando Franzini - Java Blog
K. Tsang
Bartender

Joined: Sep 13, 2007
Posts: 2624
    
    9

Hello Chris, I think you are over thinking it too much.

Data class as singleton and locking are basically 2 separate things. The Data class in my implementation is a singleton. I used a RandomAccessFile to read/write data but synchronized all the methods. Yet synchronizing all the methods may not solve the locking entirely. This is why there is the lock/unlock methods in the Sun interface.

So at the end of the day you are worrying about it you indeed did the locking right. And there is only one way to test this - use Roberto's Data class test - so you can see if it will deadlock. Or if you are doing B&S deadlock test

K. Tsang JavaRanch SCJP5 SCJD/OCM-JD OCPJP7 OCPWCD5 OCPBCD5
Chris Bicnal
Ranch Hand

Joined: Aug 17, 2005
Posts: 80
    
    1
Hi guys,

Thanks for all your help. I think I'm so concerned about my Data class as a singleton because (coming from a J2EE background) I spend my life telling people that singletons are the work of the devil - this is essentially because in a J2EE environment you can't guarantee an object to be a singleton across multiple app servers.

Anyway, back in JCD land I think I'm now happy using the singleton approach with synchronisation on each method. With each method synchronised you're essentially synchronising on the Data object itself and as it's a singleton that should simplify my locking approach.

This approach also removes the deadlock risk I had with multiple locks, although I did test with Kevin's deadlock test and it passed.

One final question on this though, regarding the requirement for a thread to wait without consuming any processor cycles when a record is locked - am I correct in thinking that in order to relinquish the lock within a synchronised method I will have to call this.wait()?

I guess that will let other threads enter other synchronised methods? And does that mean that I'll have to call this.notifyAll() prior to exiting all methods??

Thanks again for all your help! :-)

Chris
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5599
    
  15

Chris Bicnal wrote:
Anyway, back in JCD land I think I'm now happy using the singleton approach with synchronisation on each method. With each method synchronised you're essentially synchronising on the Data object itself and as it's a singleton that should simplify my locking approach.

I followed the same approach and it simplifies your code a whole lot and easy to understand for a junior developer. it is of course a bit less performant but simple, easy code is preferred above performance (according to the instructions).

Chris Bicnal wrote:
One final question on this though, regarding the requirement for a thread to wait without consuming any processor cycles when a record is locked - am I correct in thinking that in order to relinquish the lock within a synchronised method I will have to call this.wait()?


in lock-method you will have something like:


Chris Bicnal wrote:
I guess that will let other threads enter other synchronised methods? And does that mean that I'll have to call this.notifyAll() prior to exiting all methods??


When a thread has to wait, it releases the lock on the object (your data class), so another thread will acquire the lock on the data class and will execute any synchronized method. A waiting thread is waiting for a record to be unlocked (and not waiting for a record to be read for example) and only then it should get woken up, so ... (I guess you can make the correct conclusion )

Kind regards,
Roel


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Chris Bicnal
Ranch Hand

Joined: Aug 17, 2005
Posts: 80
    
    1
Thanks Roel, that all makes much more sense now.

I guess my final point of contention is around synchronizing private methods.

Within my Data class I have numerous private methods that perform common tasks (like checking whether a record number is valid for example). So, do I need to synchronize them as well, or will the fact that they can only be accessed from a public method (which will be synchronized and therefore the thread will own the lock) be enough?

Chris
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5599
    
  15

Hi Chris,

Glad my explanation made sense

If your private methods are only called from synchronized (public) methods, no need to synchronize them.

Kind regards,
Roel

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Singleton or Not?