WebServices locking/latching

и смешното става когато такава маймунка под ника Арун почва да ми обяснява точно какво върши...

> Та като думне (1 на 1000, ама думка) няма кой да маркира, че всъщност
> обработката е приключила (неуспешно). Такива ID-та могат да останат
> блокирани форевер.

Маркирай ги на startup на сървиса, нали е думнал!

[линк]

Маркирай ги на startup на сървиса, нали е думнал!

На кой точно инстанс на сървиса да ги маркира?:-)

Имаш 13 (примерно) инстанса на тоя сървис и никой от тях не знае за другите...

Проблема тука не е в това, дали да дискардваме 2-рата заявка или да я ъпдейтваме...

Въпроса е по-скоро при scale-out архитектура, как ще разбереш, че има 1-ва заявка?

Оооо, Пешо...къде одиш бе пустиняк:-)))

Аз смятам че всеки сървис трябва да е независим от клиента. Иначе няма смисъл да се използва уеб сървис. По-добре RPC. Ето ситуацията:

- Заявка 1: Искам 20 кила краставици
- Обработка
- Заявка 2: Пак искам 20 кила краставици
- Нареждаш на опашката или паралелно обработваш независима заявка за нови 20 кила крастаивици.
- Отговор на завка 2 (по-рано е приключил)
- Отговор на заявка 1 - тайм-аут грешка

И как точно ще тайм-аутнеш заявка 1, при положение, че "завяка 1" въобще си няма и на представа, че "заявка 2" съществува?

Схемата има и втора функция, но не я споменах, за да не усложнявам нещата.
Втората, следи основно за таймаути и иксепшъни. При JS я стартирам със setTimeout (...., 30000), т.е. тя се изпълнява след 30 секунди, колкото е стандартното време за чакане на таймаут, а не веднага. Ако има незатворени тикети, по преценка на правещия я, или връща грешка или рестартира неизпълнените заявки.

Може да изглежда увъртяно, но кода е 20тина реда. Относно скейлъбилити си спомням, че в началото бях направил грешка и всички заявки се пращаха наведнъж, а не през интервал. Веднъж тръгнаха около 2000 едновременно. Приблизително 1/3 дадоха таймаут, защото бяха към един и същ сървър, но останалите обработиха всичко съвсем коректно. Ако BullDog проявява интерес мога да му пусна тук примерен код на JS.

Е, пич, ти си първия дето наистина разбра къде ме стяга чепика - не може да се "познае" дали някой друг инстанс не обработва заявка със същото ID, като това дето току що се е получило в текущия инстанс. DB не решава проблема - може другия инстанс да не е комитнал и затова да не го "виждам", или пък да е комитнал и после обработката да е думнала, така че да прилича на все още обработвана, пък всъщност да се е утекла. Само някакъв "instance coordinator" май ми върши работа. Ама искам на готово, някой да го е написал ....

ОФФ: Леко с "говото", да не стане накрая "говното"!

---

Живо-здраво

>> И как точно ще тайм-аутнеш заявка 1, при положение, че "завяка 1" въобще си няма и на представа, че "заявка 2" съществува?

Заявка 1 и Заявка 2 се обработват в собствено адресно пространство от различни worker threads. Заявка 1 може даже да е направила заявка до някакъв друг уеб сървис, който в момента не работи, докато Заявка 2 да няма нужда да се свързва с този друг уеб сървис, а само с локална база данни. Съответно Заявка 2 връща отговор много по-бързо от Заявка 1, която чака примерно 2 минути, докато накрая не върне на клиента тайм-аут грешка.

Откровено казано, това са доста основни принципи на уеб програмирането също както при браузър-уеб сървър комуникация. Не знам дали си чувал за интернет и подобни модерни технологии.

Ми много сте си писали с него :)

Що не ползваш отделна таблица в ДБ-то да пишеш кво обработваш. Слагаш и един Uniq Constraint там по квото трябва. Преди да почнеш да обработваш заявката инсъртваш в нея. После като свърши делетваш рекорда или го маркираш като изпълнено - примерно. Ако думне пак пишеш в базата и така.

Или има някаква причина да не ползваш това тъй стандартно решение.

Е за тва ма кефиш баце, щото си "ебати резачката":-) Това с най-искрени чувства го казвам...сериозно!

Заявка 1 и Заявка 2 се обработват в собствено адресно пространство от различни worker threads.


Откровено казано, това са доста основни принципи на уеб програмирането също както при браузър-уеб сървър комуникация. Не знам дали си чувал за интернет и подобни модерни технологии.

А отвъд "основните приципи на уеб програмирането" кво се случва:-)))

Абе я го заеби уеб програмирането...
Кажи сега кога ще се прибираш в БГ като шефче?:-)

Май никога няма да се върна в БГ да ти стана шеф.

През базата не става, приятелю.
Има поне 2 проблема (аз май ги казах, ама сега по-подробно)
1. Тоз дето пише в таблицата (пръв), трябва и да commit-не, за да може другия (втория) да "види" записа. Както се сещаш, никоя сериозна апликация не работи с AutoCommit. Всъщност моята никога не commit-ва - аз съм с контейнер манагед стейтфул EJBs. OK, все някак си мога да го нагодя - в автономна транзакция или нещо подобно.
2. (По-сериозния проблем) - ако свършим обработката и отчетем, че сме свършили в базата - супер, сичко 6. Ко прайме обаче ако думне (както казах 1 на хилядо думкат) Остава записа в недоклатен. Такъв филм - "Ако думне пак пишеш в базата и така" е доста труден за изпълнение - мога да пресрещна някъде exception-а, ама е толкоа куц контекст - нито данни имам там, нито коннекция към базата, бе забрави.

Та затова не ползвам това "тъй стандартно решение"
Виждал съм поне 2-3 системи да се оптват да локват през базата и накрая винаги опираме до екрана, описан от Аарон, където някой маймун трябва да щрака и да вика - не, ве, не е локнат тоз запис (или по-мъжката, всяка нощ минава един скрипт и ги отнася).

Пак казвам, трябва ми координатор, дето да знае, че някой го обработва записа с дадено ID, дори повече, този някой да се отчита, че още е жив и обработва или да може да отговаря - да, ве, жив съм и още бачкам, ако го питат (или да не отговори ако е думнал). И всичкото това - cross-instance.

Май никога няма да се върна в БГ да ти стана шеф.

Аааа, не така баце...
Ти си си българче до мозъка на костите си.

Ще се върнеш, въпрос на време е.
mark my words.

как си станал роб на банката сега доживот :)