[concurrency-interest] Re: Which lock to use

Larry Riedel larryr@saturn.sdsu.edu
25 Feb 2004 13:45:38 -0000

> I have an application that is based on cached data that is being
> updated periodically (once every 5 hours).  I have a scheduler
> that is responsible for invalidating data so that data refresh can
> be made.  My problem is which locking system to use for the time
> of data refresh operation (I still have data readers coming in but
> need to hold them until I refresh the data).
> [...]
> My application is a J2EE application where many users are viewing
> with JSPs data that is held in regular java beans (not hashmap)
> in the application scope...  I do not need to get a lock from the
> start of the update process(going to the DB) but only need to get
> the lock before I invoke any of the setters on the java beans.  My
> biggest fear is that for each web hit requesting the data, the
> read operations will try to acquire the lock even though, as I
> mentioned, I update the data rarely but I have many readers of
> that data between updates.

I think from a per-request latency perspective, needlessly acquiring
a read lock would be a negligible overhead, but maybe the total
overhead for all the requests will make the application running on
the server slow.  If there is a "bean" which has several properties
that need to be all be changed as part of one atomic transaction
which comprises a sequence of updates to individual properties,
I would be inclined to make the bean a lightweight thing, a dumb
snapshot data object, and have updates occur by replacing an
old bean object with a new bean object whose properties are all
uptodate, and once that has occurred, no changes will be made to the
new bean object until after it is itself replaced and nobody has a
reference to it.  If it is ok for different JSP view pages to have
different ideas of what the state of the bean is, and there will
only be one thread updating (replacing) the beans at a particular
time, then maybe no locking is necessary at all?