Tried to mitigate with ordering of actions, but deleting an Organization revealed this really isn't an option (as it loops through child Jobs and deletes).
So much so, even got this error form Record Group page, which attempts to update Job statuses:
It appears to only be when background tasks save model instances. Reading is just fine, but a single save seems to lock up the connection.
Spark doesn't appear to have this problem, potentially because:
it uses jdbc.write, which def. doesn't present a risk
where it does save, to JobTrack, is very fast and it's unlikely to cause a problem
There were situations early on, where spark tasks were attempting to use ORM, that it had incomplete or stale data. Believe it was a separate connection than the Django runtime. However, Background Tasks are using the same one.
Tried to mitigate with ordering of actions, but deleting an Organization revealed this really isn't an option (as it loops through child Jobs and deletes).
So much so, even got this error form Record Group page, which attempts to update Job statuses:
It appears to only be when background tasks save model instances. Reading is just fine, but a single save seems to lock up the connection.
Spark doesn't appear to have this problem, potentially because:
jdbc.write, which def. doesn't present a riskJobTrack, is very fast and it's unlikely to cause a problemThere were situations early on, where spark tasks were attempting to use ORM, that it had incomplete or stale data. Believe it was a separate connection than the Django runtime. However, Background Tasks are using the same one.