Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Synchronize once a day?  RSS feed

 
Rachel McNamara
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

Upon init of my servlet, I initialize a static class that caches some
data from a database - the data is a set of objects stored in a HashMap. The data does not change very frequently so I am going to update it once a day. So here is my question...given that most of the time (23 hours a day) the data does not change, I dont want to have the overhead and serialzed nature of a synchronized method. I only want to lock the object when I am updating from the database. What is the best way to implement this?

thanks

P.S. I just read a series of articles explaining why using double checked locking on a singleton pattern wont work reliably, especially in a multi-processor environment - is there another solution?
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24215
37
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Synchronized methods aren't so expensive as they once were -- in fact, now they're quite cheap and add very, very little overhead. Most of the time people going to great lengths to avoid them are working with faulty assumptions. Why not do things the easy way, profile your application, and see if it even matters?

As far as the serialization goes: just keep the actual synchronized region as small as possible.

Finally, regarding double-checked locking: again, it's much ado about nothing. Double-checked locking is a way to avoid synchronization, but most of the time people don't bother to find out if avoiding it even matters.
 
Rovas Kram
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rachel was your question answered Ernestly or do you want your "get" methods to be mulithreaded 23 hours out of the day?
 
Paul Santa Maria
Ranch Hand
Posts: 236
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The real solution is to have two "kinds" of locks:

1. The first type of lock, "shared lock" permits concurrent access
- but only *read-only* access - to as many threads as you want.

2. The second type of lock, "exclusive lock", permits access to only
one thread at a time - but permits *read/write* access to that thread.

Here's (one of many) URLs that discuss the issues:

http://www.theserverside.com/articles/article.tss?l=Readers-Writers

'Hope that helps .. PSM
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It can be done very simply indeed.This way, without any synchronization or fancy locking, you (a) are fully threadsafe (because Data is immutable, and the reference is volatile) and (b) ensure that updates to the data are atomic, i.e. during the handling of a single request you won't find your data changing under your feet. A read/write lock achieves the same goals but at the cost of rendering you incommunicado while the data is being updated.

If you do need to go the read/write lock route, though, be sure to look at the ReadWriteLock from Doug Lea's util.concurrent package (which will be part of JDK 1.5, by the way).

I must say that you are far too worried about synchronization though. Synchronization is not that expensive anymore, and there's already enough of it happening in the application server that you won't need to worry about a single additional monitor. If you take care to keep your synchronized code short, sweet and fast then concurrency won't be an issue either.

- Peter
[ August 02, 2004: Message edited by: Peter den Haan ]
 
Vijayendra V Rao
Ranch Hand
Posts: 195
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Rachel McNamara:

I dont want to have the overhead and serialzed nature of a synchronized method.


Hi Rachel,

I guess your question has been already answered very well. I just wanted to clear out one thing in your question though. As Ernest has rightly pointed out, Synchronization is not all that an expensive overhead and this is a common
misconception
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!