Hi, The test case as presented tries to verify a more stringent condition than the original report. According to the original report, while using savepoint rollback, a commit failed, whereas the commit would succeed without a savepoint rollback. However, the attached test case is verifying whether the SQLs are issued in order, not whether the commit succeeds.
I had verified that the commit does succeed in both cases, though the order of the SQL gets modified by savepoint rollback. While a commit failure can be termed as a real bug, I am not sure whether the same can be said if the SQL ordering is not maintained. In any case, OpenJPA uses several internal collections for the inflight managed/transactional objects and not all of them warrant a stable iteration order. Of course, with savepoint rollback, maintaining the order becomes more difficult. So, with a brief analysis of the issue and given the sporadic usage of savepoint as a feature, we do not foresee at this point to force these internal collections to maintain a consistent insertion/iteration order. So as long as your application transaction does not fail under savepoint rollback, I will advise not to expect that OpenJPA will issue the SQLs in the same order. As you are aware, OpenJPA runs a topological sort to reorder the SQLs so that the database foreign key constraints are not violated. That algorithm so far has been proven robust within reason, but if the SQL reordering by OpenJPA breaks your commit when you introduce a savepoint rollback, then that is a concern and we will consider fixing it (but the resolution will be difficult as far as I can see). ----- Pinaki Poddar Chair, Apache OpenJPA Project -- View this message in context: http://openjpa.208410.n2.nabble.com/Savepoint-issue-with-OpenJPA-tp7581548p7582356.html Sent from the OpenJPA Developers mailing list archive at Nabble.com.
