снова multithreading

[Sabina]

Допустим юзер зарегистрировался на сайте и выполняется стейтмент

INSERT INTO users (userid,username)
VALUES((SELECT (MAX(userid)+1) FROM users),'name');

А если одновременно имеется несколько сессий и представим, что несколько юзеров нажали save одновременно? Как тут гарантировать уникальность выборки id?
В данном случае это снова JSP на Oracle. Речь идет о Model1, не о J2EE/MVC.

Спасибо,
Сабина

[SBolgov]

Ээээ ... вообще-то, в Oracle специально для этого generators придуманы.

[Sabina]

Ээээ ... вообще-то, в Oracle специально для этого generators придуманы.

Это какие generators? Которые часть Oracle Designer - Client/Server generators?
Мне казалось тут какое более концептуальное решение должно быть. Ну скажем как это решается в том коде, которые generators генерируют?
Есть например решение использовать sequences вместо вставки subqueries для получения нового id. Но неужели только это? Ведь казалось бы речь идет о самой распространенной ситуации...
Я просто правда не знаю, можно чуть подробнее?

Сабина

[vc]

Ээээ ... вообще-то, в Oracle специально для этого generators придуманы.

Oracle ain't got no generators. It has *sequences* if that's what you meant.

VC

[Blake]

Как тут гарантировать уникальность выборки id?

Установить нужный transaction isolation level, например "read committed"

[SBolgov]

Пардон, я действительно обозвал sequences генераторами. Сорри, перепутал. Генераторами это называлось в Interbase.

Есть например решение использовать sequences вместо вставки subqueries для получения нового id. Но неужели только это? Ведь казалось бы речь идет о самой распространенной ситуации...

А чем Вас sequences-то не устраивают?

Ситуация действительно самая распространённая, и в базе данных для этой ситуации сделан специальный механизм - sequences. Почему Вам так не хочется его использовать?

Subquery ещё и с точки производительности хуже. Сами подумайте - что дешевле: инкрементировать одну integer переменную или сделать запрос к таблице?

[Sabina]

Как тут гарантировать уникальность выборки id?

Установить нужный transaction isolation level, например "read committed"

Как тут описано?
Большое "пионерское" спасибо

А там кстати сказано

READ COMMITTED is the default isolation level in Oracle SQL

То есть получается и делать ничего не надо

Сабина

[Sabina]

А чем Вас sequences-то не устраивают?

Меня устраивают, просто хочется знать единственное ли это решение.

Сабина

[SBolgov]

А чем Вас sequences-то не устраивают?

Меня устраивают, просто хочется знать единственное ли это решение.

Разумеется, не единственное, но остальные имеют массу недостатков. А sequences, насколько я понимаю, были введены специально для того, чтобы решить данную проблему.

[Blake]

Большое "пионерское" спасибо

Большое "комсомольское" пожалуйста

[Palych]

Установить нужный transaction isolation level, например "read committed"

А кто помнит какой он по умолчанию?
Мне сдается что "read committed" и есть...

[Sabina]

А кто помнит какой он по умолчанию?
Мне сдается что "read committed" и есть...

так точно (см ссылку выше)

Сабина

[vc]

Как тут гарантировать уникальность выборки id?

Установить нужный transaction isolation level, например "read committed"

READ COMMITTED (as well as any other IL) won't ensure that 'id' will be unique in the above SQL. The provided statement, by itself, wil never work correctly.

VC

[Sabina]

The provided statement, by itself, wil never work correctly.
VC

Never ?

Сабина

[Lazy44]

Допустим юзер зарегистрировался на сайте и выполняется стейтмент

INSERT INTO users (userid,username)
VALUES((SELECT (MAX(userid)+1) FROM users),'name');

А если одновременно имеется несколько сессий и представим, что несколько юзеров нажали save одновременно? Как тут гарантировать уникальность выборки id?
В данном случае это снова JSP на Oracle. Речь идет о Model1, не о J2EE/MVC.

Спасибо,
Сабина

Change it to
INSERT INTO users (userid,username)
VALUES(your_sequence_name.nextval ,'name');

[Palych]

Интересно, Oracle позволяет сделать так:
INSERT INTO users (userid,username)
VALUES((SELECT (MAX(userid)+1) FROM users FOR UPDATE),'name');
Но это я так, из любопытства. А вообще про такие трюки лучше забыть сразу, и пользоваться генераторами встроенными в базу, или UUID...

[vc]

The provided statement, by itself, wil never work correctly.
VC

Never ?

Сабина

You said it yourself in the original message. For concurrent transactions, the SQL will produce duplicates.

"..by itself, will never work" should be re-phrased as "..by itself, should *never* be used in order to guarantee unique ids". But that's nitpicking, really.

VC

[Blake]

Сабина, "set transaction isolation" действительно не поможет

Можно еще попробовать так, но это уже не совсем multithreading:

1)lock table USERS in exclusive mode;

2)INSERT INTO users (userid,username)
VALUES((SELECT (MAX(userid)+1) FROM users),'name');

3)commit; (rollback)

[SBolgov]

Можно еще попробовать так ...:

1)lock table USERS in exclusive mode;

Гм. И чего только ни придумают люди для того, чтобы всё-таки наступить на те грабли, которые разработчики предусмотрительно убрали с дороги.

[tengiz]

Как уже было сказано, для ORACLE не существует стандартного решения этой задачи кроме как использование последовательностей или блокировка таблицы целиком. Любой другой вариант либо упрётся в ограничения модели изоляции транзакций, реализованной в ORACLE, либо потребует более, чем одного оператора SQL и обязательного наличия уникального индекса по userid (хотя такой индекс в любом случае полезен, но необязателен в случае других СУБД).

[vc]

Как уже было сказано, для ORACLE не существует стандартного решения этой задачи кроме как использование последовательностей или блокировка таблицы целиком. Любой другой вариант либо упрётся в ограничения модели изоляции транзакций, реализованной в ORACLE, либо потребует более, чем одного оператора SQL и обязательного наличия уникального индекса по userid (хотя такой индекс в любом случае полезен, но необязателен в случае других СУБД).

Hello,

Long time, no hear, have you had a nice vacation ?

1. The sequence approach is a *standard* solution (see SQL'99's SQL/Foundation part), the alternative standard being the identity column. Oracle implements the sequence generator, SQL Server does the identity column, and DB2 has both.


2. From sheer curiosity, how one would implement a unique id generation in a blocking scheduler with a *single* SQL. Hints like UPDLOCK/TABLOCK and such are considered cheating ;)

VC

[geek7]

Как тут гарантировать уникальность выборки id?

Установить нужный transaction isolation level, например "read committed"

Имелся в виду read uncommitted?

[tengiz]

Long time, no hear, have you had a nice vacation ?

Hope will have soon

The sequence approach is a *standard* solution

Так ведь я и сказал, что "не существует стандартного решения этой задачи кроме как использование последовательностей..."

From sheer curiosity, how one would implement a unique id generation in a blocking scheduler with a *single* SQL.

Использовать настоящий SERIALIZABLE (а не то, что в оракле так называется) с оригинальным запросом Сабины и никаких аномалий не будет.

[vc]

...

The sequence approach is a *standard* solution

Так ведь я и сказал, что "не существует стандартного решения этой задачи кроме как использование последовательностей..."

Ah, sorry my fault I mistakenly thought you'd meant that the sequence is a non-standard solution.

Regarding an Oracle solution without a sequence, true, *two* statements are required but *no* index is needed.

From sheer curiosity, how one would implement a unique id generation in a blocking scheduler with a *single* SQL.

Использовать настоящий SERIALIZABLE (а не то, что в оракле так называется) с оригинальным запросом Сабины и никаких аномалий не будет.

Oh, you meant this. I thought you'd had a neater trick up your sleeve ;) If one uses the true SERIALIZABLE, one should also be aware that the entire table will be locked, as the result of 'insert select max(id)+1', both for writes *and* reads. Here, SERIALIZABLE becomes SERIAL, nothing to be proud of, really. Essentially, the behaviour will be the same as in the 'solution' someone suggested for Oracle:

1. Lock the whole table
2. Do your stuff

.. no, the concurrency will be even worse, because in Oracle you can still read the locked table.

Also, it might be interesting to remind (I believe I mentioned the fact during one of our long discussions) that in version 7.x.x Oracle used to have the 'true' SERIALIZABLE whereby a table being selected from was automatically read-share locked thus preventing concurrent updates until the outstanding read transaction commits. More recent versions of Oracle retain this mode which can be enabled by setting a hidden parameter to 'true'. So technically speaking, in this mode, precisely the same *single* statement would work in the same way as it would in any locking scheduler SERIALIZABLE mode. Needless to say that the 'true' Oracle SERIALIZABLE' was not a success story due to abysmal concurrency.

In comparison to the 'true' Oracle serializable, the locking scheduler SERIALIZABLE provides more concurrency in some situations and less in others as you no doubt know. Neither is very suitable for heavily concurrent transactions. In the OP's situation, however, Oracle's 'true' SERIALIZABLE (not SNAPSHOT) would have an edge thanks to allowing concurrent reads.

All this discussion is of course purely theoretical because one should just use IDENTITY im SQL Server and SEQUENCE in Oracle and forget about possible but not concurrent alternatives.

Regards.

VC

[tengiz]

I thought you'd had a neater trick up your sleeve If one uses the true SERIALIZABLE, one should also be aware that the entire table will be locked, as the result of 'insert select max(id)+1', both for writes *and* reads. Here, SERIALIZABLE becomes SERIAL, nothing to be proud of, really.

No, that's no true. If there is a unique key (othewise select max(id) would be painful enough by istelf for large tables) on id and the DBMS supports key-range locking plus the optimizer is smart enough you can get away with only a couple of key-ranges being locked.