Re: Changing the transaction isolation level within the stored procedure?
От | Jaime Casanova |
---|---|
Тема | Re: Changing the transaction isolation level within the stored procedure? |
Дата | |
Msg-id | c2d9e70e0601250846u27ab1194sd01451a8a2c4d70d@mail.gmail.com обсуждение исходный текст |
Ответ на | Changing the transaction isolation level within the stored procedure? (Mario Splivalo <mario.splivalo@mobart.hr>) |
Ответы |
Re: Changing the transaction isolation level within the
|
Список | pgsql-sql |
> 1. java got the message via http (whatever) > 2. java does: begin; > 3. java does: select * from create_message(...) > 4. java does some checking > 5. java does: select * from set_message_status(...) > 6. java does some more checing > 7. java does commit; (under rare circumstances java does rollback). > > > Another thread (thread B) does this: > > 1. java got the update_status_request via http (whatever) > 2. java does: begin; > 3. java does: select * from set_message_status(...) > 4. java does: commit; > > As I've said, I'm using 'read commited', the default isolation level. > > Now, sometimes it happens that steps 4 or 6 take more time, and thread B > steps are executed before steps in thread A have finished. So I would > like the UPDATE in set_message_status to 'hold', until the transaction > that previoulsy called the set_message_status have commited or rolled > back. > > Is there a way to do so withing the postgres, or I need to do 'SET > TRANSACTION ISOLATION LEVEL TO SERIALIZABLE' before step 2 in both > thread A and thread B? > you need to set the transaction level after the begin and before every other statement... after the begin you have a select that invoke your function so that set is not the first statement... -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;)
В списке pgsql-sql по дате отправления: