Entity (un)locking?

[aarbit]

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

[David E Jones]

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
>
>

[jonwimp]

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
>>
>>
>
>