For whatever reason it seems that a nested transaction got out of sync with the begin/commit/rollback pairing, at least that's the only possibility I can see how the current status can occur (transaction sticks to ROLLBACKING status).
I managed to capture the ORecordOperation objects from the transaction, create a new transaction in a fresh database that has the committed state of the original one, begin the transaction, attach the ORecordOperation objects to it and to commit it. That works - almost. The records a created/updated, but links to newly created records are not set with the real RID, but with the tentative RID for new records (#<cluster id>:<negative record id>). Is there a way how to solve this (except doing it manually)? The transaction in question is still active in the memory of our customer's DB. I could try to set its status back to BEGUN and then to do a commit. However, there will be issues with the @version of several records that are to be deleted, but that have been updated from another transaction in the meantime. Is there a way to "switch off" the check, to commit and to clean up the few records later on? Overall, the situation is quite desperate, since there is a risk to loose the data. Due to the procedure described above, I'm able to keep the data, but with limitations. Due to this experience, I will now always perform commit/rollback with the 'force' flag, because our transactions are handled through JTA, which handles nesting anyway. Thanks, Markus -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
