commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <Yoav.Shap...@mpi.com>
Subject RE: TX (=transaction) Package in commons?
Date Wed, 12 May 2004 16:41:45 GMT

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:ozeigermann@c1-fse.de]
>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 <scolebourne@btopenworld.com>
>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" <ozeigermann@apache.org>
>> To: "Jakarta General List" <general@jakarta.apache.org>;
>> <commons-dev@jakarta.apache.org>
>> 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: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org




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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message