David Jencks wrote:

>Your use case does not require or even use nested transactions. You
>can easily get the effect you want by including a TransactionContext
>object in each method signature.
>
>TransactionContext {
> Object initiator
> boolean rollbackOnly
>}
>
>A transactional method receiving a null TransactionContext parameter
>creates a TransactionContext object with initiator as itself, and
>starts a transaction. It passes the TransactionContext to any
>transactional method it may call. Any method that wishes to cause the
>transaction to be rolled back sets rollbackOnly. Before a
>transactional object exits, it looks at the TransactionContext to see
>if it started the transaction: if so, it commits or rolls back as
>indicated.
>
>myTransactionMethod(TransactionContext txcx, Object[] stuff)
>if (txcx == null) {
> txcx = new TransactionContext(this);
>}
>try {
>//do stuff
>} catch (Exception e) {
>txcx.rollbackOnly = true;
>throw e;
>} finally {
>if (txcx.initiator == this) {
> if (txcx.rollbackOnly) {
> transaction.rollback();
> } else {
> transaction.commit();
>}
>}
>
>Alternatively you can use a framework such as j2ee that handles
>transactions declaratively for you.
>
>david jencks
>
>
>
>

Hi David,

I think the approach you sugested are very similar to the one we use and
tried to show.

Yes in my case aren't nested transactions, cause it's handled by fake
transactions...

When I said "I wish" nested transactions is because the objects starts
and ends the transaction (commit or rollback) by itself, since those
objects has functionality alone, when those objects was used inside a
more complex object, the "parent" object should control transaction
too, and rollback or commit the entire process.

Those "parent" object starts a transaction, and the child objects, tried
to start his own transaction, wich is not allowed.

I want to make the entire process atomic, but each method, or object,
should still, control his changes atomically too when used outside the
parent object control.

So I created this transaction stack, to help me handle, this, today I
don't need more nested transactions (for my needs).

I know nested transaction or savepoints has more features than what I
did and than my needs, I just tried to show that I wish a feature, that
I could handle by myself, and with the behaviour I wanted.

I just use StartTransaction method from my class, and commit and
rollback when needed, the class handle when do real
start/commit/rollback bases on that stack, instead of in every method
has to check if I should/shouldn't create a Transaction Context, or mark
some flag to rollback, I just raise an exception that will be catched
and handle everything. I think this method was very easy, not error
prone, and transparent...

The transaction stack has more then just this, It has some properties
and debug methods that helps me a lot.

see you !

--

Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br