Alex,
Yes, this concurrency thing can be tricky.
Try to put your operations within a single transaction whenever possible. Which really is... by
default! The de facto way to do things.
A DB transaction can help you keep your operations altogether, so error
handling and rollback is easy.
If you ever need to fork a new DB transaction to do store some data, make sure you closely examine
the data you're storing in the forked transaction. Make sure that data is NOT somehow related to
the data you're storing in your main transaction.
One example is low-level logging. Like ServerHit entity?
If you're doing low-level logging, chances are you'll need forked transactions. However, make
doubly sure that your low-level logs are not coupled to the data you're handling in your main
transaction.
Again, simply put everything in a single transaction by default. And if you have to fork a new
transaction, do it carefully.
Jonathon
David E Jones wrote:
Just standard database locking stuff. You have a couple of options:
1. change the code to be in the same transaction as the one that has the
record locked
2. wait for the lock to clear
Chances are you have either:
1. a dead-lock where thread A has a lock on record A and is waiting for
a lock on record B, and thread B has a lock on record B and is waiting
for a lock on record A
2. a paused transaction on a thread with a lock on record A, and the new
transaction attached to that thread is trying to use record A (read or
write)
So, change your code to make sure these don't happen, or to recover
nicely when they do. Not that this is always easy...
Good luck!
-David
Alex Arbit wrote:
As an update to my previous e-mail today, I think I've narrowed down the
issue.
When I try to commit data to the Subscription entity, it stalls, when I
try the same action to another table, it succeeds. It looks like the
Subscription entity is locked. Is there a way to unlock an entity?
I'm running Postgres with isolation level: read committed.
Thanks!
-Alex
