Hi, I'm also intrigued, and I also second Senor Colebourne's thought of starting this out in the sandbox.
Yoav Shapira Millennium Research Informatics >-----Original Message----- >From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] >Sent: Wednesday, May 12, 2004 11:00 AM >To: Jakarta Commons Developers List >Subject: Re: TX (=transaction) Package in commons? > >Hi Stephen! > >Decorator is a very good idea indeed! Due to internal mechanisms this >works for Maps that do not loose data (unlike LRUMap) only, but for them >I will provide decorators an option. > >As the package will depend on commons.collections I will have a closer >look at AbstractHashedMap and AbstractLinkedMap! I noticed much has >changed in the 3.0 version of commons.collections, so I will have to >refactor stuff anyway. > >Where do you think would be the right place for the transactional file >system? Somewhere inside commons? > >Oliver > > > >----- Original Message ----- >From: Stephen Colebourne <[EMAIL PROTECTED]> >Subject: TX (=transaction) Package in commons? >Date: Wed, 12 May 2004 11:50:02 +0100 > >> >> Hi! >> This looks like an intruiging package and fits what commons started out >to >> do. I'm +1 to using the sandbox here, but, as always, reserve the right >to >> kick it elsewhere on promotion if that is most applicable. >> >> Firstly I would prefer transaction over tx as its more immediately >obvious >> as to the meaning. >> >> Secondly, are you depending on [collections]? Collections has the useful >> AbstractHashedMap and AbstractLinkedMap classes which enable additional >> collections like this to be built easily. They also have the MapIterator >> which make accessing the map much easier. >> >> Finally, you might want to consider whether you can provide an >> XAMapDecorator that can decorate any other map, as this provides a lot of >> flexibility in design. (You may not even need your own hash/LRU >> implementations that way) >> >> Stephen >> >> ----- Original Message ----- >> From: "Oliver Zeigermann" <[EMAIL PROTECTED]> >> To: "Jakarta General List" <[EMAIL PROTECTED]>; >> <[EMAIL PROTECTED]> >> Sent: Wednesday, May 12, 2004 11:22 AM >> Subject: TX (=transaction) Package in commons? >> >> >>> Folks! >>> >>> I just started an effort to create a package for transactional utility >>> classes in the commons sandbox area. The aim is to seperate common >>> transaction utilities used in Jakarta Slide into a project of its own. >>> As a side-effect I would clean up interfaces and code. >>> >>> All this would result in a package called org.apache.commons.tx (or >>> org.apache.commons.transaction?). It would contain at least the >>> following stuff: >>> >>> interface XAMap extends Map, XAResource >>> --------------------------------------- >>> All retrieval / insertion of data is done using the well known Map >>> methods. Tx controll will also be done using a standard interface from >>> the JTA. This also allows to link this cache / map into a distributed >>> transaction in a J2EE container, even though this required the >>> implementation of a connector. >>> >>> abstract class XAMapBase implements XAMap >>> ----------------------------------------- >>> Base class that mainly implements XAResource >>> >>> class XAHashMap extends XAMapBase; uses HashMap, PriorityLock >>> ------------------------------------------------------------- >>> Transactional HashMap based on HashMap from java.util. Uses PriorityLock >>> from org.apache.commons.tx to allow for several isolation levels that >>> are configured in the ctor. >>> >>> clsss XALRUCache extendes XAMapBase; uses LRUMap, PriorityLock >>> ------------------------------------------------------------------ >>> Transactional Cache based on LRUMap from org.apache.commons.collections. >>> Uses PriorityLock from org.apache.commons.tx to allow for several >>> isolation levels that are configured in the ctor. >>> >>> interface MultiLevelLock / >>> ------------------------ >>> class GenericLock implements MultiLevelLock / >>> ------------------------------------------- >>> class PriorityLock implements MultiLevelLock >>> -------------------------------------------- >>> >>> Interfaces and implementations for locks that can have more than one >>> owner at different compatible levels. PriorityLock allows to specify >>> preferences of lock levels. E.g. this would allow to prefer write locks >>> over read locks. Preferences can be specified either by direction >>> (higher level over lower or vice-versa) or by an array explicitely >>> decribing the sequqnece of preferred levels. >>> >>> >>> MAYBE: Transactional file system >>> -------------------------------- >>> >>> Slide also contains a transactional file system that allows you to >>> create / delete / modify a set of files using full ACID transactions. >>> But, maybe, commons is not the right place for this? >>> >>> >>> WHAT DO I WANT FROM YOU? >>> ------------------------ >>> >>> I am looking for comments / opinions / etc. E.g. "Is commons sandbox the >>> right place for such a package?" , "Does all this already exist >>> somewhere in Jakarata or somewhere else?", "Are there any reasons I >>> should *not* do what I plan?", "Would anyone except my be interested in >>> this?" ... >>> >>> That's it and 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] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
