Ok, da ja dam par komentara na vasu pricu:
1. BindingSource nije thread safe, ali to i nije problem za njegov scenario sa formama jer sve forme rade pod istim thread-om bez obzira na to koliko ih ima. Problem nastaje samo ako se spawnuju worker threadovi koji bi radili sa tim sourcom.
2. Binding source je nezgrapan za resavanje race condition situacija, podaci se nece updatovati niti sinhronizovati sa ostalim biodovanim kontrolama dok god je binding source u edit modu. Efektivno ne postoji idealno resenje za race condition, mozes samo da hvatas eceptone koji mogu da nastanu tom situacijom i da saniras situaciju.
3. bindingsource.syncroot nije objekat za sinhronizaciju samog binding sorsa, njega lokujes kad hoces da lokujes podatke koji su ispod bindingsource-a, npr dataset na koji je nakacen. Ovim se zapravo osigurava da pristup datasetu bude vise thread safe, za slucaj da postoji drugi thread koji barata istim dataset-om preko drugog sourca-a ili direktno. Rezultat je na kraju isti u ovo scenariju, ali ovo je samo kao napomena sta se u stvari desava, i ako pravite taj thread safe wrapper, moras da lokujes ili this.syncRoot ili this SVUDA. Ako mesas i koristis oba, lako mozes da uletis u deadlock.
4. BindingSourceManager iz prethodnog posta ne resava problem. AKo pogledas kôd malo detaljnije videces da on ne cini da BindingManager bude thread-safe, on samo osigurava da dva thread-a ne mogu u isto vreme da uzmu "referencu" na bindingsource. Medjutim jednom kad dodju do reference bindingsource-a ne postoji mehanizam koji sinhronizuje pozive metodama te dve reference (koje pokazuju na istu instancu). Daklem, cela ta singleton implementacija zapravo ne postize zeljeni efekat. sorry.
Mislim da konceptualno pogresno gledate na to sta je BindingSource, on nije data access kontrola i mesto joj nije ni u data ni u business layer-u. Binding source je GUI kontrola, a dovoljan hint za to bi trebalo da vam bude cinjenica da se nalazi u System.Windows.Forms namespace-u a ne u System.Data. BindingSource nije "izvor podataka" on je "izvor bindinga", on ne manipulise podacima on se samo stara o sinhronizaciji izvora podataka na koji je nakacen i kontrola koje binduje, u kom smeru sinhronizacija ide (update controls ili update list) pritom koristeci CurrencyManager u pozadini da osigura trenuntu poziciju recorda u multi-record izvoru. To je fundamentalno SVE sto radi. Jednostavno ne postoji potreba za time da se isti BindingSource koristi za razlicite forme, koji god da je scenario postoji elegantnije resenje, jer multi-form binding sors moze da napravi mnogo vise problema nego sto donosi koristi, npr. ne mozes da koristis designer binding - sve mora kroz kôd, kad jedan forma prebaci source u edit mode - sve forme prelaze u edit mode, ako korisnike krene da edituje u dve forme i jedna forma zavrsi edit mode - zavrsava se i u drugoj sa nepredvidivim redosledom sinhronizacije dataset-a (ako je jedno polje bidnovano na dve kontrole na dva forma, iz koje kontrole/forme ce polje biti updatovano?), itd, itd.
E sad, ako pravis dve razlicite forme sa dva razlicita bindingsource-a nista te ne sprecava da bindingsource postavis na isti dataset. Iako ni sam dataset nije thread-safe (zapravo jeste za citanje opdataka, samo insert/update/delete bi morali da se sync-uju), on je bar monolitan i ne podleze problemima iz prethodnog paragrafa. A i za te operacije za koje nije thread-safe, pogledaj pod #1, dok god ti radis samo sa GUI thread-om nemas problema.
Citat:
Mikelly: Svi bindingsourceovi su na pocetnoj formi.
Imam formu na kojoj pravim racune, a na racunima se nalaze artikli. Artikli su u zasebnoj tabeli, tako da imaju svoj bindingsource. U tabeli detalja racuna nalazi se strani kljuc iz tabele artikli. Ako sad pravim neki racun, i tamo dodajem artikle, a onda bez zatvaranja te forme otvorim formu dje radim sa artiklima, i obrisem neki od njih koji se upravo nalazi na datom racunu, kako se to manifestuje?
Sta ce se desiti zavisi od dataset-a koji je ispod bindingsource-a tj kako si napravio relacije izmedju tabela detalja i artikala. Ako imas cascade delete, bice obrisan i detalj kad obrises artikal. Ako je relacija implementirana a ostane detalj a ode artikal puci ce ti exception pri brisanju jer bi brisanje artikla dovelo dataset u nereferentno stanje.
Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić
Dva toboze laka pitanja
Re: Dva toboze laka pitanja
