Bug #2221
indexes not created or being dropped during data import
100%
History
#1 Updated by Eric Faulhaber over 10 years ago
We seem to have introduced a regression to the data import process. Recent customer data imports are missing many of their original, 4GL-defined indexes from tables. In some cases, one or more indexes are present, but some are missing. In other cases, all such indexes are missing.
Obvious suspects are ImportWorker and P2JIndex.
#2 Updated by Eric Faulhaber over 10 years ago
- File ecf_upd20140108a.zip added
Index creation after a table's data import (i.e., all non-unique indexes) was happening outside of a transaction, as we were relying on the Hibernate method Transaction.isActive() to determine whether we were in an existing transaction before beginning a new one. This method is documented to be "best efforts", so the result is unreliable. It was reporting we had an active transaction in the currently open session, even though that transaction had previously been committed. As a result, a new transaction was not begun and the creation of these indexes thus was never committed to the database.
The attached update fixes this problem at the negligible expense of opening a Hibernate session and transaction for each created index.
This regression appears to have been introduced with our upgrade to Hibernate 4.1.8, which explains why it did not affect the M3 database import.
I did not regression test this update, since it affects neither conversion nor runtime behavior. However, I did confirm it is working with a substantial data import.
Committed to bzr rev. 10432.
#3 Updated by Eric Faulhaber over 10 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
#4 Updated by Greg Shah over 7 years ago
- Target version changed from Milestone 7 to Runtime Support for Server Features