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.
