Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Message-ID: <173415587.1228422404339.JavaMail.jira@brutus>
Date: Thu, 4 Dec 2008 12:26:44 -0800 (PST)
From: "David Jencks (JIRA)" <jira@apache.org>
To: dev@geronimo.apache.org
Subject: [jira] Commented: (GERONIMO-4448) TransactionManager resume method
 should only resume previously suspended transaction
In-Reply-To: <290543106.1228403684396.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/GERONIMO-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653460#action_12653460 ] 

David Jencks commented on GERONIMO-4448:
----------------------------------------

I'm not sure exactly what you see as the problem here....  IMO the behavior when "resuming" a non-suspended transaction is not specified so we don't need to check that the argument to resume is in fact suspended.

However..., what is a valid transaction?  Does the jta spec define this anywhere?

For instance.... can you suspend a transaction that is prepared but not committed?  How about if you've called setRollbackOnly() on it?

IIRC (from many years ago) the jta spec tends to not specify a lot of this behavior.

> TransactionManager resume method should only resume previously suspended transaction
> ------------------------------------------------------------------------------------
>
>                 Key: GERONIMO-4448
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-4448
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: transaction manager
>    Affects Versions: 2.2
>            Reporter: Lin Sun
>            Assignee: Lin Sun
>             Fix For: 2.2
>
>
> Currently, the resume manager resumes pretty much any transaction as long as the transaction is not null and is an instance of TransactionImpl.
> I think this is incorrect.  Per the jTA 1.1 spec, page 13:
> Suspending and Resuming a Transaction 
> A call to theTransactionManager.suspend method temporarily suspends the 
> transaction that is currently associated with the calling thread. If the thread is not 
> associated with any transaction, anull object reference is returned; otherwise, a valid 
> Transaction object is returned. TheTransactionobject can later be passed to the 
> resume method to reinstate the transaction context association with the calling thread. 
> TheTransactionManager.resumemethod re-associates the specified transaction 
> context with the calling thread. If the transaction specified is a valid transaction, the
> transaction context is associated with the calling thread; otherwise, the thread is 
> associated with no transaction. 
> Transaction tobj = TransactionManager.suspend(); 
> .. 
> TransactionManager.resume(tobj); 
> A simple test below would reveal the prob:
> {code}
>     public void testResume1() throws Exception {
>         Transaction tx;
>         assertEquals(Status.STATUS_NO_TRANSACTION, tm.getStatus());
>         tm.begin();   
>         assertEquals(Status.STATUS_ACTIVE, tm.getStatus());
>         tx = tm.getTransaction();
>         assertNotNull(tx);
>         assertEquals(Status.STATUS_ACTIVE, tx.getStatus());
>         
>         tm.commit();
>         assertEquals(Status.STATUS_NO_TRANSACTION, tm.getStatus());
>         assertNull(tm.getTransaction());
>         
>         try {
>         	tm.resume(tx);
>         	fail();
>         } catch (InvalidTransactionException e) {
>         	// expected
>         }        
>     }
> {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.