Re: [KARMA] Re: TX (=transaction) Package in commons?
Thanks, already done :) Oliver Oooops! I was just trying to check in the initial version and it seems I lack the Karma for that. Can someone grant that to me? Thanks in advance! Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TX (=transaction) Package in commons?
OK, I see. I will keep you informed about the progress. Oliver Stephen Colebourne wrote: From: Oliver Zeigermann [EMAIL PROTECTED] Where do you think would be the right place for the transactional file system? Somewhere inside commons? There is currently a move for one commons project to produce multiple jars. ie. the project groups like-minded people and similar area code together. Thus I would code under the same project to start with but separable into a different jar file. Stephen - 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]
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
RE: TX (=transaction) Package in commons?
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
Re: TX (=transaction) Package in commons?
From: Oliver Zeigermann [EMAIL PROTECTED] Where do you think would be the right place for the transactional file system? Somewhere inside commons? There is currently a move for one commons project to produce multiple jars. ie. the project groups like-minded people and similar area code together. Thus I would code under the same project to start with but separable into a different jar file. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
