Understood! I was just hoping to let them be a free rider on the success of [collections] ;)
-----Original Message----- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Sat 6/12/2004 1:40 AM To: Jakarta Commons Developers List Subject: Re: [Collection] Moving tx map wrappers into Collection Component? [collections] currently faces issues with size, ie some OSS people believe its too large. In v3.0 we kicked out the primitive collections code to [primitives] and the event based work to the sandbox [events]. It would seem to me that this sets a precedent for keeping clearly identifiable collections/groups of collections out of [collections]. So I'm -1 to adding them at the moment. Stephen ----- Original Message ----- From: "Oliver Zeigermann" <[EMAIL PROTECTED]> > I was wondering if you collection people would like to have the > transactional map wrappers I have developed in the transaction component > moved into the collection component. They might be a good supplement and > get more attention this way. > > Those wrappers work fine and each has some basic JUnit test. The wrappes > include > - a basic version doing "read committed" isolation that never blocks and > never fails upon commit > - an extended version allowing for "serializable" isolation using > pessimistic locks; the drawback is this wrapper might deadlock > - and extended verion allowing for "serializable" isolation using an > optimictic strategy; the drawback is this wrapper might fail upon commit > when conflicts occur > > All wrappers take any kind of map to be wrapped. In case you use LRUMap > or anything similar you can even implement a transactional cache with it. > > What do you folks say? > > Cheers, > > Oliver > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
