Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: TX (=transaction) Package in commons?
Date: Wed, 12 May 2004 12:41:45 -0400
Message-ID: <9C5166762F311146951505C6790A9CF80229B84F@US-VS1.corp.mpi.com>
Thread-Topic: TX (=transaction) Package in commons?
thread-index: AcQ4NEpVQ43safesR3eOrIajPypQRAAC6hgQ
From: "Shapira, Yoav" <Yoav.Shapira@mpi.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>


H=
i,
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 (=3Dtransaction) 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 close=
r
>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 fil=
e
>system? Somewhere inside commons?
>
>Oliver
>
>
>
>----- Original Message -----
>From: Stephen Colebourne <scolebourne@btopenworld.com>
>Subject: TX (=3Dtransaction) 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 (=3Dtransaction) 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 (o=
r
>>> 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 o=
ne
>>> owner at different compatible levels. PriorityLock allows to speci=
fy
>>> 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 sandb=
ox
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 interest=
ed
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.o=
rg
>>
>>
>> -------------------------------------------------------------------=
--
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.or=
g
>
>
>
>---------------------------------------------------------------------=

>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 com=
munication, and may contain information that is confidential, propriet=
ary and/or privileged.  This e-mail is intended only for the individua=
l(s) to whom it is addressed, and may not be saved, copied, printed, d=
isclosed or used by anyone else.  If you are not the(an) intended reci=
pient, 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