transaction implementation

[Costin Leau <co...@gmail.com>]

Hello,

I'm working on creating on spring support for jackrabbit and jsr-170
in general and right now there are two variants of a local transaction
manager:

1. one that uses XAResource and assigns dummy Xid's internally in
order to create a Transaction object with commit/rollback.

2. one that creates a proxy object around the session and cancels the
refresh/save methods (which act as rollback/commit). The advantage is
that this approach can work even on repositories which don't have
transaction support integrated.

I'd like to know if the second approach is a valid one; does this
approach covers all the cases inside a session? I'm concerned that the
refresh(true)/refresh(false) combination by being ignored by the proxy
yields an invalid behavior of the session (different if it were not a
proxy).
If that's the case can somebody point out a case that works okay if
using the XASession and fails when using the proxy?


Thanks.
-- 
Best regards,
 Costin                          mailto:costin.leau@gmail.com

Re: transaction implementation

[Marcin Cenkier <ma...@cognifide.com>]

Hi,

> But if you are really dying :) check out the SM JIRA and you'll find
> some uploaded code - again, it's alpha and the structure has/will be
> changed.

Great! I found it at least at 
http://opensource2.atlassian.com/projects/spring/browse/MOD-44
thanks a lot!

Cheers,
Marcin Cenkier

Re[2]: transaction implementation

[Costin Leau <co...@gmail.com>]

>>>Why don't you use JOTM and enlist XAResource in it?
>> 
>> There are two TMs - one local and one global. The difference between
>> them is that the localTM is a lightweight approach which you
>> can/should use when you don't want your transaction to be part of the
>> JTA. It's basically just an option which you can use.
>> 
>> The second TM enlists the transaction wiht the JTA transaction
>> manager(like JOTM). At first I tried to use JOTM from the beginning
>> but it's a singleton - one instance per VM so basically if you want
>> your repozitory to use local transactions inside an app server or
>> along JOTM you can't.

> Yes, but when you run inside Tomcat, it's the only way :>
Why?
> I'd see this
> resolved the way that TM is set in Spring configurtion and its either
> JOTM or some TM taken from JNDI or something totally different... So you
> can enlist resources in your favorote TM just by using JTA API - then
> you don't have to create dummy Xid but relay on external TM 
> implementation. Or am I missing something?
Let's take an example - if you are using JOTM and I enlist the XA
resource to the TM then it will be either enlisted into a new
transaction or in an already existing one and that's not what I want.
Managing the Xids by myself (which is not so elegant again) allows me
to have a very lightweight approach to the whole situation - it's
similar to HibernateTM from orm.hibernate(3) package - a single
resource TM.


I'm trying to. Just have some patience please for 2-3 more days and
I'll commit the code on Sprin Modules with everything in it. I've
already sent some alpha snapshot and it was a mess to compile all the
feedback. Just 2-3 more days and you'll get unit testing, plus
javadocs and hopefully a sample as well.
But if you are really dying :) check out the SM JIRA and you'll find
some uploaded code - again, it's alpha and the structure has/will be
changed.

-- 
Best regards,
 Costin                            mailto:costin.leau@gmail.com

Re: transaction implementation

[Marcin Cenkier <ma...@cognifide.com>]

Hello Costin,

>>Why don't you use JOTM and enlist XAResource in it?
> 
> There are two TMs - one local and one global. The difference between
> them is that the localTM is a lightweight approach which you
> can/should use when you don't want your transaction to be part of the
> JTA. It's basically just an option which you can use.
> 
> The second TM enlists the transaction wiht the JTA transaction
> manager(like JOTM). At first I tried to use JOTM from the beginning
> but it's a singleton - one instance per VM so basically if you want
> your repozitory to use local transactions inside an app server or
> along JOTM you can't.

Yes, but when you run inside Tomcat, it's the only way :> I'd see this 
resolved the way that TM is set in Spring configurtion and its either 
JOTM or some TM taken from JNDI or something totally different... So you 
can enlist resources in your favorote TM just by using JTA API - then 
you don't have to create dummy Xid but relay on external TM 
implementation. Or am I missing something?

Cheers,
Marcin Cenkier

PS.
Could you set up some read only cvs to let more people review your work? 
I'm very curious about it and can't stand waiting :-)

Re[2]: transaction implementation

[Costin Leau <co...@gmail.com>]

Hello Marcin,

First of all thanks for the reply; I was getting concern :)

> Costin Leau napisal(a):
>> Hello,
>> 
>> I'm working on creating on spring support for jackrabbit and jsr-170
>> in general and right now there are two variants of a local transaction
>> manager:
>> 
>> 1. one that uses XAResource and assigns dummy Xid's internally in
>> order to create a Transaction object with commit/rollback.

> Why don't you use JOTM and enlist XAResource in it?
There are two TMs - one local and one global. The difference between
them is that the localTM is a lightweight approach which you
can/should use when you don't want your transaction to be part of the
JTA. It's basically just an option which you can use.

The second TM enlists the transaction wiht the JTA transaction
manager(like JOTM). At first I tried to use JOTM from the beginning
but it's a singleton - one instance per VM so basically if you want
your repozitory to use local transactions inside an app server or
along JOTM you can't.

>> 2. one that creates a proxy object around the session and cancels the
>> refresh/save methods (which act as rollback/commit). The advantage is
>> that this approach can work even on repositories which don't have
>> transaction support integrated.
>> 
>> I'd like to know if the second approach is a valid one; does this
>> approach covers all the cases inside a session? 

> When you have vesionable node, you must check it out to change it, when
> change does not succseed use of refresh makes no sense - you will throw
> away all modifications, but you will have to check in the node either
> way and make a new version of it (refresh does not "rollback" from 
> checked out to checked in state). So in case of versionable nodes you
> have to use JTA (and checkout node inside transaction) and not to change
> the way refresh works - the refresh method may be used to change the
> node in other way eg. by setting other properties because former ones
> failed.

Got it. Basically I have to use XASession.


-- 
Best regards,
 Costin                            mailto:costin.leau@gmail.com

Re: transaction implementation

[Marcin Cenkier <ma...@cognifide.com>]

Costin Leau napisał(a):
> Hello,
> 
> I'm working on creating on spring support for jackrabbit and jsr-170
> in general and right now there are two variants of a local transaction
> manager:
> 
> 1. one that uses XAResource and assigns dummy Xid's internally in
> order to create a Transaction object with commit/rollback.

Why don't you use JOTM and enlist XAResource in it?

> 2. one that creates a proxy object around the session and cancels the
> refresh/save methods (which act as rollback/commit). The advantage is
> that this approach can work even on repositories which don't have
> transaction support integrated.
> 
> I'd like to know if the second approach is a valid one; does this
> approach covers all the cases inside a session? 

When you have vesionable node, you must check it out to change it, when 
change does not succseed use of refresh makes no sense - you will throw 
away all modifications, but you will have to check in the node either 
way and make a new version of it (refresh does not "rollback" from 
checked out to checked in state). So in case of versionable nodes you 
have to use JTA (and checkout node inside transaction) and not to change 
the way refresh works - the refresh method may be used to change the 
node in other way eg. by setting other properties because former ones 
failed.

Cheers,
Marcin Cenkier