[jira] Closed: (OFBIZ-1755) Odd bug related to begin()/commit() transaction

["David E. Jones (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OFBIZ-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David E. Jones closed OFBIZ-1755.
---------------------------------

    Resolution: Invalid
      Assignee: David E. Jones

The error mentioned is saying that you cannot call next() on a ResultSet that is closed.

When you commit or rollback a transaction it closes the connections related to it, which will also close ResultSets, and will make them unusable.

It's not a bug, it's how it is supposed to work.

Yes, it is possible to write code that will result in error messages.

If you want operations in transactions independent of the main transaction you need to use the suspend/resume features (part of JTA, and on the TransactionUtil class in OFBiz), and this is easiest by calling a service with the require-new-transaction attribute set to true.

But seriously, this is fairly basic JTA stuff and if this doesn't make sense start by learning about that.

> Odd bug related to begin()/commit() transaction
> -----------------------------------------------
>
>                 Key: OFBIZ-1755
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-1755
>             Project: OFBiz
>          Issue Type: Bug
>          Components: ALL COMPONENTS
>    Affects Versions: SVN trunk
>            Reporter: Skip Dever
>            Assignee: David E. Jones
>         Attachments: testcommit.zip
>
>
> This bug is difficult to explain.  Worse, it is not 100% reproducable.  If you run the enclosed testCommit() service right after starting up Ofbiz, it happens every time.  However, subsequent invocations of testCommit() may or may not cause the problem.  
> The attached code demonstrates the problem completely.  Just unzip in in your hot-deploy folder, run ant, restart ofbiz and then using the service manager, run "testCommit".   The attached view is based on ItemIssuance, so you must have shipped an item or two.  However, I expect that the code could be modified to use Party or whatever.
> To fully understand this bug, you must modify EntityListIterator.next() by adding e.printStackTrace() right below:
>         } catch (SQLException e) {
> Otherwise, the real problem is masked by the following attempt at close();
> Basically, If you have an EntityListIterator. created as shown, then you subsequently do a TransactionUtil.begin()  and TransactionUtil.commit(), the next EntityListIterator.next() call results in the exception:
> java.sql.SQLException: ResultSet not open. Operation 'next' not permitted. Verify that autocommit is OFF.
>         at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> ...
>         at org.apache.commons.dbcp.DelegatingResultSet.next(DelegatingResultSet.java:169)
> ...
>         at org.ofbiz.test.Tests.testCommit(Tests.java:91)
> This bug did not exist in the MinervaConnectionFactory code.  I have only just seen it because I was trying to move my code from a December 15th release to the latest.
> I originally thought this only existed in Derby.  However, the same error happens with Postgres.
> If you modify the test code by putting "isActiveTransaction" inside the commit, it runs just fine.  This is of course because there is already an active transaction and no commit() is really done.
> What is attempted here is a common thing whereby you read data, do some computations, then write data in between begin() and commit().
> I may be doing it wrong, but the fact remains that this worked for me for months until this latest download (which is probably long after the change was made).

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