cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Freeman Fang (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CXF-3114) WS-RM's RMTxStore's does not recover stored sequences after restart
Date Tue, 16 Nov 2010 09:15:13 GMT

    [ https://issues.apache.org/jira/browse/CXF-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932388#action_12932388
] 

Freeman Fang commented on CXF-3114:
-----------------------------------

Hi Aki,

Thanks for this patch.

But your patch break one ws/rm unit test

testRecoverReliableClientEndpoint(org.apache.cxf.ws.rm.RMManagerTest)

Could you please correct it first?
This is basically caused by EasyMock test as now you change the RMManager code, so you need
revise the mock details accordingly.

Didn't try your system test yet. One rule for the patch is that it shouldn't break anything,
you need run "mvn clean install" from root to ensure everything is ok with your patch.

Best Regards

Freeman

> WS-RM's RMTxStore's does not recover stored sequences after restart
> -------------------------------------------------------------------
>
>                 Key: CXF-3114
>                 URL: https://issues.apache.org/jira/browse/CXF-3114
>             Project: CXF
>          Issue Type: Bug
>         Environment: CXF 2.2.11 with Derby 10.6.2.1
>            Reporter: Aki Yoshida
>            Assignee: Freeman Fang
>         Attachments: rt-ws-fixes.zip
>
>
> When WS-RM's derby storage is activated, the sequence data are persisted in the database.
> However, these sequence data are not loaded from the database when the WS-RM component
is restarted.
> This problem appears to be caused by the init method of the persistence class org.apache.cxf.ws.rm.persistence.jdbc.RMTxStore
which leaves an uncommitted transaction to the relevant tables open. Consequently, the next
select statement that loads the persisted sequence data is not seeing the content.
> The original source code fragment of this method looks like this:
> {code}
>         try {
>             connection.setAutoCommit(false);
>             createTables();
>         } catch (SQLException ex) {
>             LogUtils.log(LOG, Level.SEVERE, "CONNECT_EXC", ex);
>             SQLException se = ex;
>             while (se.getNextException() != null) {
>                 se = se.getNextException();
>                 LogUtils.log(LOG, Level.SEVERE, "CONNECT_EXC", se);
>             }
>             throw new RMStoreException(ex);
>         }   
> {code}
> The suggested change would be as follows:
> {code}
>         try {
>             connection.setAutoCommit(true);
>             createTables();
>         } catch (SQLException ex) {
>             LogUtils.log(LOG, Level.SEVERE, "CONNECT_EXC", ex);
>             SQLException se = ex;
>             while (se.getNextException() != null) {
>                 se = se.getNextException();
>                 LogUtils.log(LOG, Level.SEVERE, "CONNECT_EXC", se);
>             }
>             throw new RMStoreException(ex);
>         } finally {
>             try {
>                 connection.setAutoCommit(false);                
>             } catch (SQLException ex) {
>                 LogUtils.log(LOG, Level.SEVERE, "CONNECT_EXC", ex);
>                 throw new RMStoreException(ex);
>             }
>         }
> {code}
> In the above code, the setAutoCommit(true) statement could be omitted if we simply want
to rely on the default autoCommit mode.
> In any case, the suggested code makes sure that the subsequence statement is correctly
executed.

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


Mime
View raw message