The optimistic concurrency gotcha

In my current project, I have a group of about 7 budding young developers none of whom have done any significant web development.  This includes hitching up to a database and using object relational mappers.  The one thing that always gets first-timers is stateless nature of the web.  And the first solution they come up with is session based statefulness which eventually leads to a scalability bottleneck.  The ripple effect of lack of state is that you need to have optimistic concurrency at the data access level.  Now most of us just assume that our OR Mapper will solve that for us.  And, yes, they do offer optimistic concurrency out of the box, be it with a version column or without.  But Mats Helander makes a strong point that optimistic concurrency in most (maybe all) OR Mappers actually kicks for really short durations (milliseconds).  In that case, you might as well be using good old fashioned database transactions.  Mats suggests that a way to solve the problem is to store original values in the view.  Check out Mats’ post and you’ll see why you should be storing, at the very least, your Hibernate version column/property on your view as well.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s