Na jei sedi dedes, geria kava ir transaction start, poto pageria kavute, paruko ar dar ir papietauja ir galu gale po to paredaguoja irasa ir issaugo tai gali buti padorus lock'as... 

    Juk tranzakcijas jei pvz ADO.NET galima daryti ir per ado.net connection,  pvz.:

IDbTransaction _Tran = null;

void TranStart (IDbConnection cn, bool commit) {
    // Dispatch previous transaction if active
    TranEnd(commit);

    _Tran =  (IDbTransaction)cn.BeginTransaction();
}

void TranEnd (bool commit){
    if(_Tran!=null){
        if(commit){
            _Tran.Commit();
        }
        else {
            _Tran.Rollback();
        }
        _Tran = null;
    }
}

    Tada jei atidaroma kazkas redaguoti gali eit ir kavos pagert ar pakakot :) bet cia rasau ne del to, kad taip daryti reikia, bet del to kad kad ir taip galima taip geriau nedaryti :) vat jei tokia architektura tai ja reikia tikrai keisti... Tranzakcijas reiketu laikyti tik pacios SQL operacijos metu, o jeigu reikia vistiek kazkaip rezervuoti irasus, kad pvz keli useriai ju neredaguotu tai geriau spresti su atitinkama biznio logika... 

    O tokia architektura gali turet konkrecius slowdown'us net ir esant tik keliem irasams...

JDM.


"Audrys" <oginiekienoreikalaskokiadeze@takas.lt> wrote in message news:jbnm9i$njl$1@trimpas.omnitel.net...
> jei nuo irasu kiekio ir dar tokio neispudingo juntamai mazeja nasumas - tai 
> matyt visgi yra ka indeksuoti.
> 
> "NicMC"  wrote in message news:jbnf9n$bon$1@trimpas.omnitel.net...
> 
> Sveiki,
> 
> Yra centrinis DB serveris, yra Ndešimt klientų. Susijungimus klientai
> laiko atidarytus. Kiekvienas klientas lockina teiblą, selectina vieną
> įrašą, ištrina, unlockina. Apdoroja (kelios sekundės) ir rezultatą
> insertina į kitą teiblą.
> Visa tai pakurta ant MySQL, storage - MyISAM, indeksas tik ant primary
> key (nėra ten ką indexuot, FIFO ir basta).
> Problema - nuo ~150000 įrašų lentoje bendras sistemos našumas juntamai
> pradeda mažėti.
> 
> Labai welcome bet kokios nuomonės kaip ir ką geriau tvarkyti. Kol kas
> variantai - hardware upgrade / kita DBMS / tik vienas klientas į DB,
> kuris pats QUEUE managementą darytų. O gal tiesiog InnoDB vietoj MyISAM
> ir transakcijas naudot?
> 
> Užduotis elementari - vieni softai per vieną galą grūda į DB įrašus,
> kiti softai per kitą galą juos valgo. Esminis momentas - reikalinga
> garantija, kad nei vienas valgantis klientas negaus įrašo, kurį ką tik
> gavo kitas klientas.
> 
> Taip, suprantu, ne DB darbas čia. Tiesiog softas maitinantis įrašais -
> nepajudinamas, max galima ODBC kitą pakišti. 
>