4124 workflow clean rollback #4165
Conversation
…cution system from recursive to iterative, in order to support single transaction per step execution.
| @@ -553,28 +547,18 @@ public DatasetLock addDatasetLock(Long datasetId, DatasetLock.Reason reason, Lon | |||
| } | |||
|
|
|||
| @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) | |||
| public void removeDatasetLock(Long datasetId) { | |||
| public void removeDatasetLock(Long datasetId, DatasetLock.Reason aReason) { | |||
There was a problem hiding this comment.
It looks like with this implementation that multiple locks could be removed if they share the same reason. I am assuming that we are ensuring only one lock per reason is added, or that in all cases we want all locks of a reason to be removed. Even if one of these two are true, maybe this should be renamed to reflect what is happening with the filter.
|
Looks good to me aside from my one question! |
|
Good catch, thanks @matthew-a-dunlap! |
|
The build failure seems to arise from problems in the geotoolkit repo: https://travis-ci.org/IQSS/dataverse/builds/288195273#L1784 Need to try and rebuild after Monday noon. |
| @OneToOne(mappedBy = "dataset", cascade = {CascadeType.REMOVE, CascadeType.MERGE, CascadeType.PERSIST}, orphanRemoval = true) | ||
| private DatasetLock datasetLock; | ||
| @OneToMany(mappedBy = "dataset", cascade = CascadeType.ALL, orphanRemoval = true) | ||
| private Set<DatasetLock> datasetLocks; |
There was a problem hiding this comment.
Ah ha! This change to support multiple locks is what @sekmiller and I believe we need for #4139 to fix a bug related to dataset leaving the in review state when the curator uploads a tabular file: #4139 (comment)
|
Closing in favor of pull request #4216. |
Related Issues
Pull Request Checklist
General discussion
The core issue here was the fact that when an
InReviewdataset is starting the pre-publication workflow, it should be locked twice: first for the in-review, then for the workflow. This way, if the workflow fails, theInReviewlock stays.To implement this, Datasets now have multiple locks. The API became simpler, though, because of the new method
dataset.isLockedFor( DatasetLock.Reason ). Using this is an improvement over(dataset.getLock() != null && dataset.getLock().getReason == REASON.It's also a nice infrastructure for having multiple locks (e.g. a few PIs have to approve publication, multiple background processes...)