openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pinaki Poddar <>
Subject Re: Savepoint issue with OpenJPA
Date Fri, 21 Dec 2012 23:49:29 GMT

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:
Sent from the OpenJPA Developers mailing list archive at

View raw message