Maybe I wasn't clear. What I intended to say is that, if the version does NOT match in the application, you already have a stale object. After that, you execute the update and NH will use the version AGAIN. Let me do an example:
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. If DTO RowVersion != 2, FAIL AT THIS POINT* c. Update business object properties from DTO (*no need to update RowVersion, already validated in b*) d. Save business object and commit transaction Session 2 closed If there is ANOTHER update between a and d, you'll get a StaleObjectStateException. Diego On Tue, Apr 20, 2010 at 17:02, NK <[email protected]> wrote: > 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]> > <nhusers%[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]<nhusers%[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]<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 at http://groups.google.com/group/nhusers?hl=en.
