by lucabaldini » 29 March 2012, 9:56
A dire il vero non dovrebbe essere così nel senso che se tu fai il checkin di un oggetto, In.de sceglie automaticamente tutti gli altri checkin che ritiene necessari per far sì che la copia master sia integra. Forse c'è un caso in cui questo calcolo automatico non funziona correttamente (è un algoritmo complesso che non deve portare sempre tutti i lock sul server ma non deve portare oggetti parziali o incompleti). Per esempio: se tu crei una tabella nel DB, In.de prende un lock di tipo INSERTED sulla tabella. Poi crei una classe nell'applicazione a partire da quella tabella. In.de prende un lock di tipo INSERTED sulla classe. Ora, se fai il checkin dell'applicazione (o della classe), In.de effettua anche il checkin del lock sulla tabella dato che la classe non può andare dentro da sola (dipende dalla tabella e ne ha bisogno per vivere). Questo viene fatto automaticamente a vari livelli cercando di portare il numero minimo di lock necessario a mantenere integra la copia master.
Quell'algoritmo raggruppa anche modifiche effettuate all'interno della stessa modifica. Se fai una modifica (es: cancelli una classe), In.de prende lock su tutti gli oggetti collegati che vengono cancellati a causa della cancellazione della classe. Tutte i lock presi sono "raggruppati" nel senso che sono lock presi all'interno della stessa modifica. Ora, se fai il checkin di uno qualunque di quei lock, In.de effettua il checkin di tutti gli altri lock nello stesso "gruppo".
Pertanto, se ti capita di vedere comportamenti che non sono chiari o che non ti aspetti, contattaci in assistenza così controlliamo e vediamo che tutto funzioni come previsto.