TX (=transaction) Package in commons?

[Oliver Zeigermann <oz...@apache.org>]

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

Re: TX (=transaction) Package in commons?

[Stephen Colebourne <sc...@btopenworld.com>]

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" <oz...@apache.org>
To: "Jakarta General List" <ge...@jakarta.apache.org>;
<co...@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