commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <Yoav.Shap...@mpi.com>
Subject RE: TimerMap
Date Mon, 24 Nov 2003 19:15:26 GMT

Howdy,
I also agree it's still a Map.

Another option is consistent with the rest of the (JDK and Jakarta)
collections framework: throw UnsupportedOperationException if you don't
want to support iterator or keySet or whatever.

Yoav Shapira
Millennium ChemInformatics


>-----Original Message-----
>From: James Carman [mailto:james@carmanconsulting.com]
>Sent: Monday, November 24, 2003 2:09 PM
>To: 'Jakarta Commons Developers List'
>Subject: RE: TimerMap
>
>I don't know if I would NOT implement Map.  It's somewhat analagous to
the
>TreeMap warning that it doesn't support nulls if the Comparator doesn't
>support nulls.  That's what I was saying.  When choosing your
>implementations of collections, you have to weigh the benefits/costs of
>each
>implementation type.  This would just be one of those costs (the fact
that
>iterating is dangerous).
>
>-----Original Message-----
>From: Arun Thomas [mailto:arun.thomas@paybytouch.com]
>Sent: Monday, November 24, 2003 2:01 PM
>To: Jakarta Commons Developers List
>Subject: RE: TimerMap
>
>
>IMHO, if the intention is that this class should be used only in
contexts
>(the specific cases) that are _always_ aware of the implementation,
then I
>would be -1 to implementing the Map interface - even if the methods are
the
>same.  I would also then change the interface to represent only those
>methods that ought to be used in this context - put/get, removing
values()
>and keySet() in particular.
>
>On another point - any reason why TimerMapKey is public?
>
>I still think it's something very useful!
>
>Cheers,
>-AMT
>
>-----Original Message-----
>From: James Carman [mailto:james@carmanconsulting.com]
>Sent: Monday, November 24, 2003 10:36 AM
>To: 'Jakarta Commons Developers List'
>Subject: RE: TimerMap
>
>
>I wouldn't worry so much about the iterator issue.  Remember, this map
>implementation is to be used in specific cases.  And, when somebody
uses
>it,
>they should probably understand that there are multiple threads
modifying
>the map.  I would say that you can get by with a warning in the JavaDoc
on
>this one.  No need to get overly complicated here IMHO.
>
>-----Original Message-----
>From: Arun Thomas [mailto:arun.thomas@paybytouch.com]
>Sent: Monday, November 24, 2003 1:24 PM
>To: Jakarta Commons Developers List
>Subject: RE: TimerMap
>
>
>Seems like a cool idea....  However, I'm concerned about the following
>points in the implementation:
>
>If the timer expires after an iterator on the keys or values is
obtained,
>the underlying map is modified directly - this means that the next
access
>to
>the iterator (see HashMap javadoc) will throw a
>ConcurrentModificationException.  To my mind, this makes iteration over
>this
>map fairly difficult, particularly as many algorithms which use maps
>probably do use iterators to access the data in the map.  A possible
>solution - provide wrapping implementations of Set/Collection which
return
>FilterIterators that filter out expired items during iteration - only
>deleting those items after all existing iterators have completed
iteration
>or have been destroyed.  This gets complicated quickly, however.
>
>It seems (perhaps I'm missing something) to be overkill to synchronize
all
>accesses to the TimerMap.  I'm not quite sure why this is necessary - I
>don't think the implementation can guarantee that an object will be
expired
>at the instant the timer runs out - I don't believe TimerTask provides
this
>guarantee.  Therefore, the synchronization seems to be unneeded - the
>expired object will be removed "soon" after the expiry time is reached.
>
>Cheers,
>-AMT
>
>-----Original Message-----
>From: Joseph Rosenblum [mailto:joey@25thstreet.net]
>Sent: Sunday, November 23, 2003 11:04 PM
>To: commons-dev@jakarta.apache.org
>Subject: TimerMap
>
>
>Commons Developers,
>
>The attached class is a very simple implementation of the java.util.Map
>interface that gives each key a TTL (time to live) in the map. I've
>found this extremely useful as a backing store for certain types of
>caches (where you want to expire items based on time in cache, as
>opposed to LRU, etc..) and for tracking services that I want check the
>availability of. It's called TimerMap and takes a long TTL in the
>constructor.
>
>I'd love to donate this code to the commons, please let me know if you
>find it useful.
>
>-Joe
>
>Joseph Rosenblum | 25th Street Networks
>Easy, Reliable Web Hosting @ http://www.25thstreet.net/
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org




This e-mail, including any attachments, is a confidential business communication, and may
contain information that is confidential, proprietary and/or privileged.  This e-mail is intended
only for the individual(s) to whom it is addressed, and may not be saved, copied, printed,
disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately
delete this e-mail from your computer system and notify the sender.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message