Using transactions

[Pa...@capgroup.com]

Whenever one declares a transaction for an object, should you also declare
a transaction for objects that are part of the primary object ?
Sample:

Object A {
     Object B
}

If A opens a transaction and B opens one, what if B fails ?
Is it faster not to open a new transaction in B and simply rely on A's
transaction ?

I am quite confused, I know :-)

Regards,

Patrick Reyes

Re: Using transactions

[Thomas Mahler <th...@web.de>]

Hi Patrick,

The general recommendation is: Use nested transactions only if 
definitely required.

In your case, where you are working against a single database, there is 
no real need to open nested tranasctions. SO the best thing is to use 
only one in the top level.

You will need nested transactions if you are programming transactions 
consisting of substransactions against *different* backendsystems.
This is also known as 2 phase commit.
The top level transaction is only allowed to commit if all 
subtransactions succeed.
If one of the subtransactions fails the top level tx is rolled back and 
via the 2-phase commit all subtransactions that have been executed 
already will also rolled back.

To make 2-phase commit work your target systems must comply to certain 
standards (XA, JTA).

cheers,
Thomas


Patrick_Reyes@capgroup.com wrote:
> Whenever one declares a transaction for an object, should you also declare
> a transaction for objects that are part of the primary object ?
> Sample:
> 
> Object A {
>      Object B
> }
> 
> If A opens a transaction and B opens one, what if B fails ?
> Is it faster not to open a new transaction in B and simply rely on A's
> transaction ?
> 
> I am quite confused, I know :-)
> 
> Regards,
> 
> Patrick Reyes
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
> 
>