Hi, Thanks CK for the detailed reply.
Yes timestamping is a good option but it can present problems while updating. The "Locked flag" and unlock mechanism that you suggested will be a more reliable option in case of such volumimous application. I was interested in knowing different practical approaches from members as per their experience that how generally concurrency scenario is tackled in high volume applications like Banking,trading systems etc. Kindly contribute your thoughts if anybody else has used different approach for handling such scenario. CK, once again thanks for replying. Regards Hrishi On 9/19/08, CK <[EMAIL PROTECTED]> wrote: > > There are many ways that it can be done, timestamping rows is a good > one as it means when an update is performed, the current timestamp can > be compared against the one fetched when the data was loaded, however > this can be problematic as the user may have issues in updating their > data. > > I would recommend adding a locked flag to the header row (for example > in a banking situation you would lock the person, which could then be > used to lock their accoutns, addresses etc.) so that when another user > attempts to enter that row in the system, they receive a warning that > the data is read only and cannot be changed. You could then have some > kind of notification system when the row becomes unlocked etc. > > THere are other solutions as well, you should look at what you are > trying to implement, what the main problems could be, then try and > come up with a solution. > > It is hard to suggest a general best solution as all applications are > different. > > On 18 Sep, 18:10, "Hrishikesh Ranalkar" <[EMAIL PROTECTED]> wrote: >> Hi, >> >> In case of high volume transaction applications one major aspect which >> needs to be considered while developement is to tackle/avoid the >> concurrency errors. >> >> There can be several standard techniques/approaches used to check this >> like - >> >> 1. Timestamp method for checking the data change >> 2. Data adapter handles the locking internally. etc.. >> >> I would like to know are there any other approaches/solutions in .Net >> that can be used to avoid the concurrency errors or multiple user >> accesssing same record scenario? Are there any other ways apart from >> the 2 i mentioned above? >> >> Kindly share your experiences/thoughts in how this scenario is tackled >> in such high volume transactional applications. >> >> Regards >> Hrishi > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DotNetDevelopment, VB.NET, C# .NET, ADO.NET, ASP.NET, XML, XML Web Services,.NET Remoting" 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://cm.megasolutions.net/forums/default.aspx -~----------~----~----~----~------~----~------~--~---
