Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Message-ID: <1375421299.1228423964275.JavaMail.jira@brutus>
Date: Thu, 4 Dec 2008 12:52:44 -0800 (PST)
From: "Lin Sun (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=12653474#action_12653474 ] 

Lin Sun commented on GERONIMO-4448:
-----------------------------------

Hi David, thanks a bunch for the comment!

If you look at the test case, the test should not fail, because the tx here is an invalid transaction. But when I ran the test with G's txmanager, it would fail because we didn't check if the transaction was from a previously suspended transaction. I agree that the spec didn't mention if it is ok to suspend a transaction that is prepared but not committed or roll back only. For the resume method, the JTA spec says the transaction obj from suspend can be passed into the resume method and gives an example on that. I think I interpreted it as only the previously suspended transaction can be passed into the resume method as valid transaction. Comments?

Lin

> 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.