You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2003/11/24 23:59:20 UTC
Re: [collections] TimerMap
This sounds good from the discssions. I would definitely want to to extend
AbstractMapDecorator if it is a decorator.
One solution to troublesome iteration issues can be to clone the data into
an ArrayList in the constructor of the iterator. The iterator can then
access the data safely. This solution has to be javadocced of course.
Stephen
----- Original Message -----
From: "Arun Thomas" <ar...@paybytouch.com>
Actually, I'm only concerned about keySet().iterator() and
values().iterator(). Not about keySet() and values() :)
Perhaps something that can be worked in as we move forward? I think this
(the "ill-formedness" of the iterators) could be something captured in docs
today and implemented explicitly moving forward. Perhaps I'll take a shot
once we've got it checked in....
Now if only I can find my password for CVS :) I should be able to check it
in....
-AMT
-----Original Message-----
From: James Carman [mailto:james@carmanconsulting.com]
Sent: Monday, November 24, 2003 12:42 PM
To: 'Jakarta Commons Developers List'
Subject: RE: TimerMap
Maybe you could just go ahead and throw UnsupportedOperationException on
keySet(), but implement a generic debugCachingIssues() method! ;-)
-----Original Message-----
From: Joseph Rosenblum [mailto:joey@25thstreet.net]
Sent: Monday, November 24, 2003 3:40 PM
To: Jakarta Commons Developers List
Subject: Re: TimerMap
Hey there,
Thanks for all the feedback! Ideally, I think this makes the most sense
as a Map --since it's most common use cases are as a Map-- and the
javadoc would spell out usage scenarios and challenges (something I
will work on).
I've changed two points: TimedMapKey is now private and the backing
store is no longer synchronized (as per Arun's suggestions).
Synchronization can be left to the client developer.
Even though I wouldn't want to have client code accessing entries via
iterator in normal usage, I don't think calling keySet() should throw
an UnsupportedOperationException since examining the keySet of such a
map could be very useful in debugging caching issues.
Thanks,
-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
RE: [collections] TimerMap
Posted by James Carman <ja...@carmanconsulting.com>.
That would work! It's probably not a big issue if the iterator actually
returns an object that has expired from the cache. Typical usages of these
implementations aren't necessarily concerned with the EXACT timing of
removal from the map. Even if they are, they're not GUARANTEED that the
objects will be removed at EXACTLY the TTL value anyway.
-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
Sent: Monday, November 24, 2003 5:59 PM
To: Jakarta Commons Developers List
Subject: Re: [collections] TimerMap
This sounds good from the discssions. I would definitely want to to extend
AbstractMapDecorator if it is a decorator.
One solution to troublesome iteration issues can be to clone the data into
an ArrayList in the constructor of the iterator. The iterator can then
access the data safely. This solution has to be javadocced of course.
Stephen
----- Original Message -----
From: "Arun Thomas" <ar...@paybytouch.com>
Actually, I'm only concerned about keySet().iterator() and
values().iterator(). Not about keySet() and values() :) Perhaps something
that can be worked in as we move forward? I think this (the
"ill-formedness" of the iterators) could be something captured in docs today
and implemented explicitly moving forward. Perhaps I'll take a shot once
we've got it checked in....
Now if only I can find my password for CVS :) I should be able to check it
in....
-AMT
-----Original Message-----
From: James Carman [mailto:james@carmanconsulting.com]
Sent: Monday, November 24, 2003 12:42 PM
To: 'Jakarta Commons Developers List'
Subject: RE: TimerMap
Maybe you could just go ahead and throw UnsupportedOperationException on
keySet(), but implement a generic debugCachingIssues() method! ;-)
-----Original Message-----
From: Joseph Rosenblum [mailto:joey@25thstreet.net]
Sent: Monday, November 24, 2003 3:40 PM
To: Jakarta Commons Developers List
Subject: Re: TimerMap
Hey there,
Thanks for all the feedback! Ideally, I think this makes the most sense as a
Map --since it's most common use cases are as a Map-- and the javadoc would
spell out usage scenarios and challenges (something I will work on).
I've changed two points: TimedMapKey is now private and the backing store is
no longer synchronized (as per Arun's suggestions). Synchronization can be
left to the client developer.
Even though I wouldn't want to have client code accessing entries via
iterator in normal usage, I don't think calling keySet() should throw an
UnsupportedOperationException since examining the keySet of such a map could
be very useful in debugging caching issues.
Thanks,
-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