[jira] Created: (TQL-9) Forced commit after SQLException

Forced commit after SQLException
--------------------------------

                 Key: TQL-9
                 URL: http://jira.codehaus.org/browse/TQL-9
             Project: TranQL
          Issue Type: Bug
         Environment: Tranql-connector 1.2 or 1.3, XaPool 1.5, jenks 1.3
            Reporter: Sylvain Mougenot


I'm facing a problem with Geronimo / TranQl-connector / XaPool.
I've to perform several request (insert / update).
If one of them throw a SQLException (unique constraint violation for exemple)
the former requests get commited !!! This is bad!!!

After some debug I found where it breaks down.
First Tranql intercept the SQLException.
Then given a particular ExceptionSorter (that's the point) it decides to notify
of Connection Error.
Geronimo gets this notification an treat the connection as a bad one : it
delist this resource form transaction.
Thus the connection get back to the pool.
At this very last step, the setAutoCommit is called (normal if we want to reset
the connection in its original state). But this call is equivalent to a commit.
And because no one but Tranql saw the SQLException yet, no business code could
be done before. Meaning we couldn't fire a rollback yet.

The main problem is all SQLException are considered as Fatal because, in XaPool
1.5, in the class XAPoolDataSourceMCF the constructor gives
AllExceptionsAreFatalSorter instance to Tranql. This could be a default
behaviour but we need to be hable to overwrite this.

Patch : add a constructor for XAPoolDataSourceMCF
public XAPoolDataSourceMCF(ExceptionSorter exceptionSorter) {
super(new StandardXADataSource(), exceptionSorter);
}

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/TQL-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107829 ]

David Jencks commented on TQL-9:
--------------------------------

I'm confused.  AFAICT tranql doesn't have a XAPoolDataSourceMCF class.  Furthermore if geronimo is notified of a connection Error it should not be putting the connection back in the pool but rather destroying it.  Are you sure of the geronimo behavior you claim?  Where are the classes you are talking about?

The idea behind the base classes in tranql is that you should write an ExceptionSorter specific to the db you are using so this kind of exception does not get treated as fatal.... unfortunately there is no consistency between dbs about what is a fatal and what is non-fatal.

> Forced commit after SQLException
> --------------------------------
>
>                 Key: TQL-9
>                 URL: http://jira.codehaus.org/browse/TQL-9
>             Project: TranQL
>          Issue Type: Bug
>         Environment: Tranql-connector 1.2 or 1.3, XaPool 1.5, jenks 1.3
>            Reporter: Sylvain Mougenot
>
> I'm facing a problem with Geronimo / TranQl-connector / XaPool.
> I've to perform several request (insert / update).
> If one of them throw a SQLException (unique constraint violation for exemple)
> the former requests get commited !!! This is bad!!!
> After some debug I found where it breaks down.
> First Tranql intercept the SQLException.
> Then given a particular ExceptionSorter (that's the point) it decides to notify
> of Connection Error.
> Geronimo gets this notification an treat the connection as a bad one : it
> delist this resource form transaction.
> Thus the connection get back to the pool.
> At this very last step, the setAutoCommit is called (normal if we want to reset
> the connection in its original state). But this call is equivalent to a commit.
> And because no one but Tranql saw the SQLException yet, no business code could
> be done before. Meaning we couldn't fire a rollback yet.
> The main problem is all SQLException are considered as Fatal because, in XaPool
> 1.5, in the class XAPoolDataSourceMCF the constructor gives
> AllExceptionsAreFatalSorter instance to Tranql. This could be a default
> behaviour but we need to be hable to overwrite this.
> Patch : add a constructor for XAPoolDataSourceMCF
> public XAPoolDataSourceMCF(ExceptionSorter exceptionSorter) {
> super(new StandardXADataSource(), exceptionSorter);
> }

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

     [ http://jira.codehaus.org/browse/TQL-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Jencks closed TQL-9.
--------------------------

      Assignee: David Jencks
    Resolution: Fixed

Some recent changes should have fixed the situation.

First of all, based on other peoples' experience, I think that a connection error event is getting fired which the pool (certainly jencks does this) will use to destroy the connection, so it won't get back in the pool.
Also, we now have a way of configuring whether to try to rollback work before destroying the connection.  If the connection is really dead and you cant communicate with the db, then you don't need to try to rollback.... you couldn't communicate this instruction.  However, if you can't tell if the connection is still usable, its safer to try to roll back work.

Finally, the generic adapter has an exception sorter that has a list of non-fatal SQLCodes.  We're trying to improve this list, if you have information you can share that would be very much appreciated.

> Forced commit after SQLException
> --------------------------------
>
>                 Key: TQL-9
>                 URL: http://jira.codehaus.org/browse/TQL-9
>             Project: TranQL
>          Issue Type: Bug
>         Environment: Tranql-connector 1.2 or 1.3, XaPool 1.5, jenks 1.3
>            Reporter: Sylvain Mougenot
>            Assignee: David Jencks
>
> I'm facing a problem with Geronimo / TranQl-connector / XaPool.
> I've to perform several request (insert / update).
> If one of them throw a SQLException (unique constraint violation for exemple)
> the former requests get commited !!! This is bad!!!
> After some debug I found where it breaks down.
> First Tranql intercept the SQLException.
> Then given a particular ExceptionSorter (that's the point) it decides to notify
> of Connection Error.
> Geronimo gets this notification an treat the connection as a bad one : it
> delist this resource form transaction.
> Thus the connection get back to the pool.
> At this very last step, the setAutoCommit is called (normal if we want to reset
> the connection in its original state). But this call is equivalent to a commit.
> And because no one but Tranql saw the SQLException yet, no business code could
> be done before. Meaning we couldn't fire a rollback yet.
> The main problem is all SQLException are considered as Fatal because, in XaPool
> 1.5, in the class XAPoolDataSourceMCF the constructor gives
> AllExceptionsAreFatalSorter instance to Tranql. This could be a default
> behaviour but we need to be hable to overwrite this.
> Patch : add a constructor for XAPoolDataSourceMCF
> public XAPoolDataSourceMCF(ExceptionSorter exceptionSorter) {
> super(new StandardXADataSource(), exceptionSorter);
> }

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email