This post originated from an RSS feed registered with Java Buzz
by Carlos Perez.
Original Post: Why Can't Locking Be Abstracted Away?
Feed Title: .:Manageability:.
Feed URL: http://www.manageability.org/blog/stuff/rssDisabled?portal_status_message=Syndication+is+Disabled
Feed Description: Random thoughts on the manageability of complex software.
One of the core motivations of EJB is to abstract away locking, the thought is that a developer shouldn't have to worry about concurrency issues when developing business objects. It's quite a reasonable vision, however it's more fantasy than reality.
I have no issues against separation of concerns, and I do believe that in many cases a developer shouldn't have to worry about concurrency issues. My main beef is that there's this insidious believe that it's possible to abstract away concurrency.
Concurrency is really a no brainer if you're stateless or when you don't share anything. When you do have to share something, then that's when you need someway to resolve the conflict. In general locking and its corresponding protocols (i.e. transactions) are mechanisms to resolve conflict in shared resources. We could choose to believe, as many do, that locking is done at the lowest levels of code and can be abstracted away at the higher levels. However this belief is entirely erroneous.
Computer Science tends to have a habit of creating models of the world that don't reflect reality. Take for example the preoccupation of pure functional languages, that is languages that don't have state. The reason why the theoreticians love it is because its easy to apply analytic tools to discover new insights. However, it's got a fatal flaw, just like most mathematics, there's absolutely no concept of time. Unfortunately, time exists in the real world, functional languages do have their place, however they break down quite too easily to real world requirements.
The problem with locking now is that it also exists in the real world, it's an avoidable reality. You all learned this in childhood, things are indeed shared! We could for a subset of business rules focus on things that aren't shared, that would be easy. However, business by its very nature is about interaction, with interaction comes sharing. It's simply unavoidable not to discuss or implement at a high level how things are to be shared.
Now it would be easy if everything were shared in the same way, that is the assumption of pure pessimistic locking systems. That is, sharing by reservation, that is cancellation of reservation without consequences. Fact is, that's not reality, I can't hold a reservation forever nor should be no consequences if I cancel it.
Sharing is also about coordination, after all reality is that time isn't free, we need to build mechanisms to make coordination efficient. That's why there's such a thing as optimistic locking, it assumes that you can make copies of the thing that's shared, and possibly in some future time resolve the conflicts when you merge those copies together. We all love the convenience of not having to wait to do work on a system like CVS where optimistic locking is in effect. However, we cannot hide the fact, that if there's a conflict, some human needs to get involved to resolve it.
Now if you reflect a bit about most of the programs that we use most often today, it's quite obvious that most of it is about coordination and not computation. Computer Science seems to be stuck with this old mind set that it's all about computation, well sorry, but that only applied back in the 50's.
In short, it's all about coordination, and if you can build effective coordination mechanisms then you're on the right track to solving the real problem. To say that it can be abstracted away isn't solving the problem, it's denying the problem exists. So I wonder, is the EJB world in denial?
Previous Topic
