Relying on Commons Transaction

[Oliver Zeigermann <oz...@c1-fse.de>]

Folks!

I am currently in the process of cleaning all XAResource implementations 
to be more spec conforming. This is needed for external transactions 
which require this.

I have started a transaction package in the sandbox area of the Jakarta 
Commons Project which initially holds the locking and file system 
classes from the Slide project and some transactional map wrappers. All 
Jakarta committers are granted commit access on request.

I will add an AbstractXAResource that combines all the tedious work to 
be done in most XAResource implementations in Slide and in the 
transaction package itself.

For the next release of Slide I want to remove all work that is doubled 
in the transaction package from Slide in order for me to have a single 
source to maintain. This would require to rely on this transaction 
package which is still in the sandbox. This however does not mean any 
problem as all Slide committers will be granted access to it on request 
(as I already said above).

If anyone has any objections to this speak now or be quiet forever.

Oliver

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

Re: Relying on Commons Transaction

[Oliver Zeigermann <oz...@c1-fse.de>]

Stefan Lützkendorf wrote:

> Hello Oliver, I have no objections, it whould be great
> if the txn stuff is more reusable.
> 
> What are the main problems where the implementations are
> non conforming? Or is it to much say it shortly?
> I ask because of our onw store implementation, that may
> have the same problems.

Main thing is how suspend and resume is handled done by calls to start 
and end in XAResource. Upon suspend the current thread must be 
dissotiated from the specified transaction and in resume it must take up 
work again.

I will check in a first version of the fixed version for the file store 
soon. Have a look at the changes as a reference then.

Oliver

> 
> Thanks, Stefan
> 
> Oliver Zeigermann wrote:
> 
>> Folks!
>>
>> I am currently in the process of cleaning all XAResource 
>> implementations to be more spec conforming. This is needed for 
>> external transactions which require this.
>>
>> I have started a transaction package in the sandbox area of the 
>> Jakarta Commons Project which initially holds the locking and file 
>> system classes from the Slide project and some transactional map 
>> wrappers. All Jakarta committers are granted commit access on request.
>>
>> I will add an AbstractXAResource that combines all the tedious work to 
>> be done in most XAResource implementations in Slide and in the 
>> transaction package itself.
>>
>> For the next release of Slide I want to remove all work that is 
>> doubled in the transaction package from Slide in order for me to have 
>> a single source to maintain. This would require to rely on this 
>> transaction package which is still in the sandbox. This however does 
>> not mean any problem as all Slide committers will be granted access to 
>> it on request (as I already said above).
>>
>> If anyone has any objections to this speak now or be quiet forever.
>>
>> Oliver
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> 


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

Re: Relying on Commons Transaction

[Stefan Lützkendorf <lu...@apache.org>]

Hello Oliver, I have no objections, it whould be great
if the txn stuff is more reusable.

What are the main problems where the implementations are
non conforming? Or is it to much say it shortly?
I ask because of our onw store implementation, that may
have the same problems.

Thanks, Stefan

Oliver Zeigermann wrote:
> Folks!
> 
> I am currently in the process of cleaning all XAResource implementations 
> to be more spec conforming. This is needed for external transactions 
> which require this.
> 
> I have started a transaction package in the sandbox area of the Jakarta 
> Commons Project which initially holds the locking and file system 
> classes from the Slide project and some transactional map wrappers. All 
> Jakarta committers are granted commit access on request.
> 
> I will add an AbstractXAResource that combines all the tedious work to 
> be done in most XAResource implementations in Slide and in the 
> transaction package itself.
> 
> For the next release of Slide I want to remove all work that is doubled 
> in the transaction package from Slide in order for me to have a single 
> source to maintain. This would require to rely on this transaction 
> package which is still in the sandbox. This however does not mean any 
> problem as all Slide committers will be granted access to it on request 
> (as I already said above).
> 
> If anyone has any objections to this speak now or be quiet forever.
> 
> Oliver
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> 



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