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.



"NicMC" <jzs@freemail.lt> wrote in message news:jbnq7t$tvp$1@trimpas.omnitel.net...
> On 2011.12.07 13:56, Laimis wrote:
>> InnoDB. Isolation level Serializable. Ir papasakosi čia, kaip pasikeitė
>> sparta.
> 
> Pagooglinau, pabandžiau, veikimo mechanizmas visiškai analogiškas, ar 
> bus nauda? Gal aš per daug noriu, bet pabandysiu paaiškinti dar kartą.
> 
> Kiekvienas klientas pasiima tik 1 įrašą šitaip:
> 
> LOCK WRITE
> SELECT * FROM `table` ORDER BY ID ASC LIMIT 1
> DELETE FROM `table` WHERE `ID` = (iš SELECT'o)
> UNLOCK
> 
> Esmė - nei vienas klientas neturi teisės gauti įrašo, kurį jau gavo 
> kitas. Taigi SELECT neturi grąžinti to įrašo. Row-level lockingas rakina 
> įrašus UPDEITUI, bet ne SELECTUI. Viskas puikiai sukosi ir su 300000 
> įrašų, kai buvo tik 20 klientų. Šiuo metu klientų jau beveik 50. Ir jau 
> prie 150000 įrašų prasideda bėdos.
> 
> OK, su InnoDB galima perrašyti taip:
> BEGIN
> SELECT * FROM `table` ORDER BY ID ASC LIMIT 1 FOR UPDATE
> DELETE FROM `table` WHERE `ID` = (iš SELECT'o)
> COMMIT
> 
> O koks tolkas? Vis tiek likę klientai lauks...
> 
> Spėju, kad vis tik lieka keliai - hardware upgreidint / padaryti kažkokį 
> queue managerį, kuris iš DB selectintų daug, o jau paskui padalintų po 
> vieną.