[concurrency-interest] Which lock to use

Katz Guy Guy_Katz@icomverse.com
Wed, 25 Feb 2004 14:34:37 +0200


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3FB9B.BB04FDB8
Content-Type: text/plain

Thanks for the quick reply,
I am actually listening to your J1 presentation as we speak.
I want to provide some more info so maybe the recommendation can be more
decisive.
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.
Like you mentioned, 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.
Does this shed some more light?
Thanks.

-----Original Message-----
From: Doug Lea [mailto:dl@cs.oswego.edu] 
Sent: Wednesday, February 25, 2004 2:23 PM
To: Katz Guy
Cc: 'concurrency-interest@altair.cs.oswego.edu'
Subject: Re: [concurrency-interest] Which lock to use


> 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).
> Are Objects like ReadWriteLock suitable for this kind of case? Should I
stay
> with regular synch? What options do I have here?
> Any help would be appreciated.

This doesn't say enough to make a concrete recommendation but it is
the sort of situation where read/write locks should work well.  Also,
if (1) your cache is structured as a map (2) it is OK for readers to
use previous values even while updates are being performed (rather
than blocking until updates complete), then you should be able to use
a ConcurrentHashMap as the cache, without any custom coding.

-Doug




______________________________________________________________________
  This email message has been scanned by PineApp Mail-Secure and has been
found clean.

------_=_NextPart_001_01C3FB9B.BB04FDB8
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [concurrency-interest] Which lock to use</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Thanks for the quick reply,</FONT>
<BR><FONT SIZE=3D2>I am actually listening to your J1 presentation as =
we speak.</FONT>
<BR><FONT SIZE=3D2>I want to provide some more info so maybe the =
recommendation can be more decisive.</FONT>
<BR><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>Like you mentioned, 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. =
</FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>Does this shed some more light?</FONT>
<BR><FONT SIZE=3D2>Thanks.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Doug Lea [<A =
HREF=3D"mailto:dl@cs.oswego.edu">mailto:dl@cs.oswego.edu</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, February 25, 2004 2:23 PM</FONT>
<BR><FONT SIZE=3D2>To: Katz Guy</FONT>
<BR><FONT SIZE=3D2>Cc: =
'concurrency-interest@altair.cs.oswego.edu'</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [concurrency-interest] Which lock to =
use</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; I have an application that is based on cached =
data that is being updated</FONT>
<BR><FONT SIZE=3D2>&gt; periodically (once every 5 hours).</FONT>
<BR><FONT SIZE=3D2>&gt; I have a scheduler that is responsible for =
invalidating data so that data</FONT>
<BR><FONT SIZE=3D2>&gt; refresh can be made.</FONT>
<BR><FONT SIZE=3D2>&gt; My problem is which locking system to use for =
the time of data refresh</FONT>
<BR><FONT SIZE=3D2>&gt; operation (I still have data readers coming in =
but need to hold them until I</FONT>
<BR><FONT SIZE=3D2>&gt; refresh the data).</FONT>
<BR><FONT SIZE=3D2>&gt; Are Objects like ReadWriteLock suitable for =
this kind of case? Should I stay</FONT>
<BR><FONT SIZE=3D2>&gt; with regular synch? What options do I have =
here?</FONT>
<BR><FONT SIZE=3D2>&gt; Any help would be appreciated.</FONT>
</P>

<P><FONT SIZE=3D2>This doesn't say enough to make a concrete =
recommendation but it is</FONT>
<BR><FONT SIZE=3D2>the sort of situation where read/write locks should =
work well.&nbsp; Also,</FONT>
<BR><FONT SIZE=3D2>if (1) your cache is structured as a map (2) it is =
OK for readers to</FONT>
<BR><FONT SIZE=3D2>use previous values even while updates are being =
performed (rather</FONT>
<BR><FONT SIZE=3D2>than blocking until updates complete), then you =
should be able to use</FONT>
<BR><FONT SIZE=3D2>a ConcurrentHashMap as the cache, without any custom =
coding.</FONT>
</P>

<P><FONT SIZE=3D2>-Doug</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________________________=
_______</FONT>
<BR><FONT SIZE=3D2>&nbsp; This email message has been scanned by =
PineApp Mail-Secure and has been found clean.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3FB9B.BB04FDB8--