What would a software developer reality show look like?
Now there’s a thought. Would it even be interesting? I recently heard of an organization donating a day of 30 developers on the company payroll, and the developers themselves committing another day resulting in 60 man hours of high powered raw software development power. How about that for a reality show?
Maybe you have an idea you’d like to share? If so, drop me a note at btaylor@sswug.org. Who knows what we might come up with?
Accidental DBA –and Optimistic Locking
Many times as a software developer you must play the role of the Database Architect as well. This is a role that many developers take on quite readily, especially when database requirements are straight forward.
I have found that a normalized database can have a fairly close connection to business objects, given certain allowances. For this reason you have seen the adoption of tools such has Hibernate, nHibernate, NetTiers and more recently, Entity Framework. The close approximation of these code generation tools, and repeatable accuracy of bug free software often outweighs the purist considerations an object oriented programmer may hold.
What does this have to do with Optimistic locking and the Accidental DBA? The short answer, everything. It is important for you to understand that these frameworks are designed around some method of handling multi-user concurrent persistence requirements…one being concurrency. In short, what do you do when two users have modified a record in the same table having the same key? Who’s update is kept; who’s update is denied?
Last year I talked about the timestamp data type in SQL Server. Adding a column to a table with a TimeStamp data type can optimize testing if your update would overwrite updates from another process.
If two persons get the same record from a table, independently modify the data, and then attempt to save the data back to the database, then the current data from the database must be compared with a snapshot of the record as you received it in order to assure you would not overwrite changes made by another.
Using a TimeStamp data type in your table allows the system to compare the TimeStamp you received when you retrieved the before snapshot with the current value in order to determine if the data had been modified by another process. Without that TimeStamp data type column in your table, it must compare each column in the row to determine if a modification has been made.
The short story is, if you are using optimistic locking in your database, consider using a column in your table having a TimeStamp datatype in order to improve performance of your optimistic concurrency.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Troubleshooting problems with indexes in SQL Server 2008 R2
In this article, Alexander Chigrik explains some problems that you can have when you work with indexes in SQL Server 2008 R2.
Featured White Paper(s)
Top 10 Tips for Optimizing SQL Server Performance
read more)