[jbosscache-dev] Re: JBCACHE-874 (WAS: JBCACHE-315 and 1.4.1)
Manik Surtani
manik at jboss.org
Mon Dec 4 17:12:29 EST 2006
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik at jboss.org
Telephone: +44 7786 702 706
MSN: manik at surtani.org
Yahoo/AIM/Skype: maniksurtani
On 4 Dec 2006, at 17:31, Brian Stansberry wrote:
> Manik Surtani wrote:
>> Yeah, I may do a CR1 tomorrow anyway, and get JBCACHE-315 and JGroups
>> 2.4.1 in CR2 now. There are enough changes from fixing
>> JBCACHE-871 and JBCACHE-875 to warrant a CR, as these are
>> pretty big changes.
>
> It's not a big deal if JBCACHE-874 doesn't go in 1.4.1.CR1, but it
> would
> be nice to get it in so it's out in the wild longer before the GA.
Sorry yes, forgot about this.
>
> This is a switch from LinkedList to LinkedHashSet as the data
> structure
> in TransactionEntry; there's a forum post linked to the JIRA that
> explains why.
>
> I can probably do this today, but wanted to point out a couple things
> and get feedback:
>
> 1) A bunch of the LinkedList fields in TransactionEntry are protected.
> Changing them to LinkedHashSet therefore technically changes the API.
> This is an internal class, so I don't think that's an issue. Any
> objections?
I'm ok with this, I don't think it will break the
OptimisticTransactionEntry subclass. In fact, is there any reason
why this needs to be protected? Could we make do with stronger
access protection than protected?
>
> 2) A number of TransactionEntry methods return List and currently hand
> out a ref to the internal data structure. The caller of these methods
> logically expects a List so I think the API should remain the
> same. So,
> that implies the methods would do something like "return new
> ArrayList(internalSet);"
>
Hmm, I guess so. Perhaps in 2.0.0, change this to return a Collection?
>
> If there are any concerns about this, it doesn't need to get done
> today
> or go in CR1.
>
> - Brian
More information about the jbosscache-dev
mailing list