[
https://issues.apache.org/jira/browse/OFBIZ-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Skip Dever updated OFBIZ-1755:
------------------------------
Attachment: testcommit.zip
> 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
> 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.
