I don't want to use application version checking, because it is not completely fool-proof. The database is the ultimate system of records, not the domain. So if the version matches in the application, it does not guarantee me that when I execute the update, the database will have the same version in the domain.
If the database was modified in the brief period of loading the entity in the second session and running the update statement, I would have broken the optimistic concurrency check. The only way to ensure this would be to put an update lock on the record at the time of read to ensure consistency, but this would be a huge no no. Thanks for your advise! On Apr 16, 7:44 pm, Diego Mijelshon <[email protected]> wrote: > Maybe I don't understand your logic, but what are you expecting exactly? > To get a StaleObjectStateException? > > You have already gone to the DB, and you have two row versions to compare, > one in the DTO and one in the fresh-loaded persistent instance. If they > don't match, you can fail immediately, without going to the DB again. > > Diego > > > > > > On Fri, Apr 16, 2010 at 12:45, NK <[email protected]> wrote: > > Hi, > > > We use a DTO pattern in our application to send information to several > > clients applications from our central business logic server which uses > > NHibernate for ORM. We are trying to implement optimistic concurrency > > control using the version property. The version is generated by the > > database (SQL Server Timestamp column). > > > Here is the sequence of actions > > > Client 1 requests data > > Session 1: > > a. Load business object (RowVersion 1) > > b. Copy business object properties to DTO along with row version > > Session 1 closed > > > Client 2 updates data of the same business object (RowVersion 2) > > > Client 1 submits updated data > > Session 2: > > a. Load business object (RowVersion 2) > > b. Update business object properties from DTO along with row version > > (RowVersion 1) > > c. Save business object and commit transaction > > Session 2 closed > > > In session 2, when the update statement is generated (call to public > > void NullSafeSet(System.Data.IDbCommand cmd, object value, int index) > > in our custom timestamp column), the "value" param is taken from the > > business object loaded in the session, rather than the value updated > > from the DTO. > > > I have read forum posts saying that the RowVersion should not be > > touched, but we cannot avoid this in a DTO pattern. Is there any way > > to work around this? We are 2 years into the development and cannot > > remove the DTO pattern. I am sure this is not a new problem and would > > really appreciate any help. > > > Thanks!! > > > -- > > You received this message because you are subscribed to the Google Groups > > "nhusers" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<nhusers%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/nhusers?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "nhusers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group > athttp://groups.google.com/group/nhusers?hl=en.- Hide quoted text - > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
