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>
Message-ID: <40C619FB.6090309@apache.org>
Date: Tue, 08 Jun 2004 21:56:43 +0200
From: Oliver Zeigermann <ozeigermann@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: [Transaction]: Anyone intersted in contributing?
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Folks!

I have just finished what might be called my "first sketch" of a 
transaction package. In order to make this a "real" project I need 
people who would like to contribute!

It includes locks, transactional maps (both pessimistic and optimistic) 
and a file section including a transactional wrapper to the file system 
and a fail safe persistent file sequence.

What may be missing are preference locks, more map wrapper 
implementations with other strategies/isolation levels, a deadlock 
detection for the locking, etc.

The motivation for the move to start this package was to make code from 
the Slide project more genrally available. On one side others may find 
it useful and on the other side maybe someone else would like to contribute.

I am for sure not "mister transaction", so what can be found there 
merely is a starting point. I am sure there must be lots of people doing 
better than / different from what I have done!

Maybe this just isn't interesting? I disagree! Possible use cases range 
from transactional maps / caches in J2EE environment (there already is a 
tiny bit of (bad) code that plugs the map into a XA transaction using 
JCA and even a full configuration for JBoss) to your everyday work. 
Imagine a Swing client application where you do complex stuff (maybe 
talking to one or more servers) and the user is allowed to cancel the 
whole operation. Or it might be needed to be canceled because of errors. 
Now image all the results have been stored in a transactional map, you 
simple do a rollback on errors and a commit upon success. It will even 
be possible to have as much threads as you like to work on that map each 
of them totally unaware of the other (at least until a commit).

OK, this was long! Sorry for that...

So, anyone?

Cheers,
Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org