[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