Nu žiūrėk, pabandysiu duoti analogišką pavyzdį kas bandomas išburt. 
Pabrėžiu iš anksto, su jokiais emailais tai neturi nieko bendro, bet 
kaip pavyzdys - tiks puikiai.

Turiu lentą:
Numeris,
e-meilas,
Tekstas,
Sukūrimo data

Softo užduotis - paimti vieną eilutę, išsiųsti laišką, kitoj lentoj 
padėti rezultatą (išsiųstas ar ne). Softas threadintas, vienu metu 
veikia 6 threadai (nu, geresniuose servuose iki 16).
Pradiniam variante buvo txt failas su duomenimis, failai kilnojami 
rankom ir t.t. Pirmas updeitas - padaryta DB, softas jungiasi prie DB, 
kiekvienas threadas pasiima vieną eilutę, ją ištrina, kitas threadas jau 
gauna kitą eilutę. Performance padidėja - lagino vis tik iš failų 
skaityt po eilutę.
Poreikis didėja, atsiranda antras servas su tokiu pačiu softu, tik 
jungiasi į pirmo servo DB. Dar vienas. Ir dar. Šiuo metu - jau 8 servai, 
threadų iš viso arti 50. Užkrovus į lentelę 150000 įrašų, bendras 
performance jau krenta. Nu, būtų dzin - 150000, tai čia dienos norma 
jiem. Bet kas dieną kilnot - užkniso.
Shared networked queue demoną daryt noro mažai, tikėjaus su DB išspręst, 
bet panašu, kad nerealu.

P.S. Su meilais tas neturi tikrai nieko bendra.

On 2011.12.07 16:03, Jornada Del Muerto wrote:
> Sveiks,
>
> Nezinau man tai nesiziuri sitai, ipac delete, ne paprasciau butu
> spresti su verslo logika, pvz. sukurt lenta tipo
>
> table_name_locks -------- _userId PK _recordId PK date DATETIME -
> tipo lockijimo data del visa ko
>
> (cia toks iprotis laukai kurie tiesiogiai nerodomi UI turi priekyj
> underscore _ simboli, o kurie rodomi ne, tada ivairus db selectu
> isvedimo UI komponentai turint 1 konfiguruojama bool parametra
> showUnderscores true/false gali juos rodyti arba ne, tokio standarto
> paprastai laikausi db projektuodamas ir UI komponentai taip padaryti
> kad i tai atsizvelgia, del to parasius paprasciausia select * from
> blabla UI komponentas rodys tik laukus kuriuos turi matyt useris)
>
> Nu ir jei kazkoks irasas paimamas redagavimui tai darai cia insert
> jei jo dar nera, na jei bus ir darysi errora mes.
>
> Ir po to useriui loadini irasus tipo:
>
> SELECT * FROM table_name WHERE _recordId IN ( SELECT _recordId FROM
> table_name_locks WHERE _userId = XXX )
>
> Ta prasme krauni butent siuo selectu tai ka jis redaguoja tada jei
> luzteli kazkas ir sekanti kart eis sis selectas vistiek tures tai ka
> paemes redaguot, o kada paredaguoja tada is table_name_locks tiesiog
> pasalini irasa ir ji gali imt kiti.
>
> Tuo paciu gali kiti useriai matyt kas ka redaguoja, kad nevargtu
> jamt, pvz daro paieska:
>
> SELECT T.*, U.name userName, TNL.date FROM table_name T LEFT JOIN
> table_name_locks TNL On T._recordId = TNL._recordId LEFT JOIn (useriu
> table .... ) U
>
> WHERE (... blabla salygos...)
>
> ANYWAY Duomenu naikinimas su DELETE yra blogas dalykas ...
>
> P.S. Siulyciau is viso vengt technologiniu sprendimu, na kaip tavo
> atveju tam tikra biznio logika nori uzkart tranzakcijoms.. cia toks
> naujos kartos programmeriu budas viska sukart ant technologiju, bet
> daznai poto tai brangiai kainuoja in long run... siuo atveju
> nenaikini duomenu ir elementari logika susitvarkytu graziai su
> viskuo.
>
> JDM.