commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arun Thomas" <arun.tho...@paybytouch.com>
Subject RE: TimerMap
Date Mon, 24 Nov 2003 20:24:28 GMT
I suppose my objection to this is really grounded around the fact that the user of this class
has no means to control whether or not this is actually usable as a fully specified Map. 
Other implementations do exist which may not satisfy the constraints of the default contract,
but, as with TreeMap, it is _possible_ to comply with that contract.  In this case, because
the TimerTask is hidden in the implementation, it isn't really possible to do that....  There's
no way that a user can manage the usage of this class to reliably avoid the exception.  

I do see the relationship with WeakHashMap - although the API (as documented in the javadoc)
makes no claims, the Sun implementation does handle this issue - it prevents the garbage collector
from cleaning up a reference once it has been checked for by hasNext().  It doesn't prevent
a user thread from modifying the map in such a way that the ConcurrentModificationException
is thrown, but the internal processes are prevented from doing this.

* That said, OK, I'm only -0 :)  I do like the UnsupportedOperationException on the iterator()
idea though!
* I'm definitely in agreement that this is useful for caching and the like.  
* I also like the idea of making it a decorator - it's already implemented mostly as one -
a decoration on HashMap.   Let's make that explicit - it will also simplify implementation
is this becomes a subclass of AbstractMapDecorator.
* Any reason why clear() has a null implementation - I think it should delegate as well....

-AMT



-----Original Message-----
From: __matthewHawthorne [mailto:matth@phreaker.net] 
Sent: Monday, November 24, 2003 11:13 AM
To: Jakarta Commons Developers List
Subject: Re: TimerMap


But, in a sense, how is this different than any other Map which may have 
other threads accessing it?  Care needs to be taken to avoid problems.

I think that the nature of this Map's behavior would require the creator 
to call Collections.synchronizedMap before any use, to avoid the 
concurrent modifications.  However, that doesn't mean that every piece 
of an application which accesses the Map needs to know this.  From their 
perspective, it's just another Map.

Question: What happens if you use a WeakHashMap, and one of the keys are 
garbage collected while you're iterating through it?  (Is this even 
possible?)

I think it's a good idea, could be used for caching.  It's a special 
Map, but it's still a Map.




Arun Thomas wrote:
> 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


Mime
View raw message