DBMS 에서 트랜젝션으 구현하기 힘든 이유가 말씀하신 그런 이유들 때문입니다.

트랜젝션 구현시 가장 먼저 고려해야 할 점이 그런 지금과 같은 그런 상황이죠.

바꾸어 말하면, 말씀하신 상황들에 대한 대처는 충분히 해결되도록 구현되어 있는 것이 트랜젝션의 이점이죠.

즉 사용자는 그런 고려를 할 필요가 전혀 없다는 것입니다.

테스트해 보시면 이해를 할듯...

메뉴얼 12.2절 transaction isolation 부분이 참고 될 것 같습니다.

위와 같은 경우라면 pgsql의 default transaction isolation level인 read committted에서는 문제가 될 수 있습니다. 먼저 실행된 트랜잭션에서 update한 후에 commit을 안한 상태에서 다른 트랜잭션에서 update를 하면 우려하시는 일이 생기니까요.

dirty read가 필요한 상황 처럼 보이지만 pgsql은 dirty read를 지원하지 않기도 하고 그것이 정답은 아니구요. lock을 생각해야 할 것 같습니다.

두가지 방법이 있을 것 같은데요. 하나는 row level lock을 사용하는 방법과 table lock을 사용하는 방법입니다.

row level lock은 트랜잭션이 끝나기 전에 특정 row에 대해서 lock을 걸어서 update가 안되게 하는 것입니다. UPDATE 명령 전에 UPDATE될 컬럼들에 대해서 SELECT ... FOR UPDATE 구문을 먼저 실행시켜버리는거죠. 이렇게 하면 먼저 실행된 트랜잭션이 commit 되거나 rollback되기 전에는 해당 row들이 lock 상태이기 때문에 다른 트랜잭션에서 실행한 SELECT ... FOR UPDATE 명령이 처리되지 않고 기다리게 됩니다.

table lock은 아시겠지만 table 전체에 lock을 걸어버리는 방법이지요. 확실한 방법이기는 하지만 동시 처리 성능을 심각하게 떨어트리게 됩니다.

update할 row의 수가 전체 table의 일부라면 row lock을 그렇지 않다면 table lock을 쓰는 것이 좋을 것 같네요.

경험상 그런 상황이면 자동으로 먼저 테이블을 변경한 트랜젝션이 끝날때까지 기다리지 않나요?

특별히 작업하지 않으면, shared lock 이 걸려, 
우려한 사태가 발생합니다. 

그런 사태라면, 
반드시 

select ... for update 형태로 일단 자료를 가져오고, 
그 다음 update 구문을 사용하든지, 

아니면, 
lock table ... row exclusive 또는 exclusive로 
row 또는 table을 배타적으로 잠궈야합니다.

성철님 말이 맞아요. ^^