If I've a TransactionManager class that's a singleton; meaning one manager handling clients' transaction requests, do I need to synchronize all of the instance methods within that singleton class?
My understanding is that I should; otherwise, there's a chance of data corruption when one thread tries to update, but another thread tries to delete the same record at the same time.
If the Singleton is initialized lazy you have to synchronize the getInstance method due to the Java memory model. For a comprehensive explanation on this see http://www-128.ibm.com/developerworks/java/library/j-dcl.html.
If in your methods you're accessing(R/W) object fields, then synchronization is maybe a good idea.
i believe it's better to instantiate all singletons eagerly. what is lazy instantiation buying you?
the only way lazy makes sense to me is:
(1) if there's a good chance that you'll never use the singleton,
(2) if the instantiation is very expensive.
if (1) is true, i'd wonder why the singleton was written in the first place, and if (2) is true i'd prefer paying the cost on startup rather than make my first user bear the entire burden.
makes no sense to me. don't do it. be eager.
%
besides, double checked locking used to be broken. unless java 5 or 6 have changed the memory model to fix it, it's a waste of time anyway.
if your singleton is doing write operations on its state, you have to synchronize those. i'm assuming you're asking about the instance method, the one that instantiates the singleton in the first place.
%
Let's say that you have a singleton that is handling the printing in a desktop application. This could be time consuming and it will not probably be used too often. On the other hand you could not say that it will never be used.
In a web application, response time is much more important than initialization time (which can be easily ignored). In this case, of course, eager initialization makes much more sense.
> Please help understand the differences b/w lazy and
> egar singleton.
And while you guys are at it, please explain what it has to do with the orignal question.
Yes tom, you will need to synchronize any operation that modifes data along with any operation that reads modifiable data. Note that this only applies to data that is in JVM owned memory. If you are talking about database records or other external records, that's a different question entirely.
> Let's say that you have a singleton that is handling
> the printing in a desktop application. This could be
> time consuming and it will not probably be used too
> often.
What's time consuming about instantiating the object?
> On the other hand you could not say that it
> will never be used.
Exactly. If that were so, why write it?
> In a web application, response time is much more
> important than initialization time (which can be
> easily ignored).
Never ignored. It's just a question of when you want to pay.
Web app as opposed to desktop app? Does response time not matter for them?
> In this case, of course, eager
> initialization makes much more sense.
I'm arguing that eager initialization always makes more sense. Lazy for singletons ought to be the exception, not the norm.
%
> And while you guys are at it, please explain what it
> has to do with the orignal question.
instance method put me in the mind of creation, but after thinking a bit more I realized that it was about synchronization in general.
> Yes tom, you will need to synchronize any operation
> that modifes data along with any operation that reads
> modifiable data. Note that this only applies to data
> that is in JVM owned memory. If you are talking
> about database records or other external records,
> that's a different question entirely.
"if your singleton is doing write operations on its state, you have to synchronize those."
That's my response to other methods.
%
> "if your singleton is doing write operations on its
> state, you have to synchronize those."
>
> That's my response to other methods.
>
> %
This is true, but it may not be sufficient. For instance if the singleton is doing read operations from other mutable objects, and needs two reads to be atomic, then those two reads must be enclosed in a sync block that syncs on the same lock as any write operations to those objects.
The point being, that, as somebody stated earlier, we can't know exactly what needs to be synced w/o knowing what this singleton does and how it interacts w/ other objects.
> > Let's say that you have a singleton that is
> handling
> > the printing in a desktop application. This could
> be
> > time consuming and it will not probably be used
> too
> > often.
>
> What's time consuming about instantiating the
> object?
I just took this an example. The idea was to give an example of a Singleton of which instance is making the initialisation (and a time-consuming one) in the constructor.
>
> > On the other hand you could not say that it
> > will never be used.
>
> Exactly. If that were so, why write it?
I said that you will use it, but probably rarely. For example in a word processing application, you will not use the printing all the time. You can open the application, edit a document and then exit. You haven't used the printing module, so why initialise it? On the other hand when you need it, it should work and you can wait for its initialisation.
>
> > In a web application, response time is much more
> > important than initialization time (which can be
> > easily ignored).
>
> Never ignored. It's just a question of when you want
> to pay.
In a web application is very important that the response time for your clients to be short. You can wait a little bit longer when starting the web server without any problems.
>
> Web app as opposed to desktop app? Does response
> time not matter for them?
Yes, for both, but in different ways.
>
> > In this case, of course, eager
> > initialization makes much more sense.
>
> I'm arguing that eager initialization always makes
> more sense. Lazy for singletons ought to be the
> exception, not the norm.
>
> %
On the other hand, I think we deviated from the original post a little bit to much, so I'll end here.
