Пример: биллинг (упрощенно):
Для простоты не будет описываться через триггеры
и опустим вычисление цены звонка (только изменим стоимость минуты):
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
create table Phone
(
id_phone int not null primary key,
phone varchar( 30 ),
time_from timestamptz, -- время действия
time_to timestamptz, -- телефона
price float
);
create unique index ix_phone_phto on Phone (phone,time_to);
create table Call
(
phone varchar( 30 ) not null,
time_start timestamptz not null,
time_stop timestamptz not null,
id_phone int,
price float,
primary key (phone,time_start)
);
create index ix_call_phone on Call
(
id_phone,
time_start
);
create index ix_call_phone_1 on Call
(
phone,
time_start,
(coalesce(id_phone,- 1 ))
) when (coalesce(id_phone,- 1 )=- 1 );
Заполним талицу Phone:
1.
2.
insert into Phone values ( 1 ,'2345678','2005-03-01','3000-01-01', 2 . 30 );
insert into Phone values ( 2 ,'7654321','2005-03-01','3000-01-01', 4 . 60 );
Пусть одновременно выполняются 2 транзакции (будем помечать точки во времени):
1-я:
Шеф дает указание: "Придурков с телефона '2345678' в этом месяце считать по 3.70!!! Ты не забыл?"
Вы понимаете, что забыли и выполняете (естественно с помощью пары кнопок на форме):
1.
2.
3.
4.
5.
6.
7.
8.
9.
-- точка времени 2
begin;
update Phone set time_to='2005-04-01' where id_phone= 1 ;
insert into Phone values ( 3 ,'2345678','2005-04-01','3000-01-01', 3 . 70 );
-- вторая транзакция не завершилась, потому не считаем '2345678' по 3.70
update Call set id_phone= 3 , price= 3 . 70 where id_phone= 1 and time_start
between '2005-04-01'::timestamptz and '2005-05-01'::timestamptz;
-- точка времени 3
commit;
2-я транзакция вставляет телефоны и билингует их:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
-- точка времени 1
begin;
insert into Call (phone,time_start,time_stop) values ('2345678','2005-04-29 10:00:01','2005-04-29 10:01:29');
insert into Call (phone,time_start,time_stop) values ('7654321','2005-04-29 10:00:35','2005-04-29 10:02:15');
-- точка времени 2
-- первая транзакция не завершилась, потому считаем '2345678' по 2.30
update Call set id_phone=ph.id_phone ,price=ph.price from Phone ph where ph.phone = phone and time_start between time_from and time_to
and coalesce(id_phone,- 1 )=- 1 ;
-- точка времени 3
commit;
Можем теперь сделать выборку и убедиться:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
select count(*) as c from Call where id_phone= 3 ;
/*
c
------
0
*/
select phone,price from Call group by phone,price;
/*
phone | m
--------+----
2345679 | 2.30
7654321 | 4.20
*/
При True Serializable такого не возникнет: либо первая трагзакция начинается
раньше и вторая считает как "3", либо вторая считает как "1", а первая
изменяет.
Самое интересное: при READ COMMITTED вероятность такого бага меньше:
завершись одна из транзакций до точки 2, вторая отработает правильно.
Можно разбить вторую на ввод данных и обсчет, но все равно : если первая
транзакция началась до commit ввода данных и завершилась после update
второй, ошибка будет.
Единтсвенный выход: использовать явный LOCK. Причем мое мнение:
1.
2.
3.
4.
5.
6.
7.
-- в первой транзакции :
begin;
LOCK Phone,Call IN SHARE;
-- во второй :
begin;
LOCK Phone IN SHARE;
LOCK Call IN ROW SHARE;
Кто сможет обойтись без LOCK, прошу рассказать, буду признателен.
Только прошу протестить, что бы ни каких возможностей для данного глюка; я
этот пример (не в точности, но изоморфный) сног до головы перевертел.
SELECT FOR UPDATE не спасает (как мне кажется) - он не увидит еще не
вставленные строки, да и возвращать 2000 строк, уже тарифицированных в
этом месяце как "1" (по 2.30) - sucks.
Заранее признателен !!!
