Howto implement hand-rolled locking with SQL?

Question

Hi there,
For now I used java.util.Concurrent's classes for locking critical sections which should only be modified/read by a client at a time. However now one customer would like to cluster our app and I wonder wether the locking could also be done with SQL.
The reason why we don't use some high-level SQL constructs is that our product only uses a really very small subset of SQL.
Any ideas wether/how double-checked locking could be implemented using SQL?
Thank you in advance, lg Clemens

Answer 1

Here is a link to a nice discussion on your topic.
It might or might not help, but it did appear
pertinent to your questions by talking about
alternative methods and pros and cons of
auto-incrementing.Ooooh are we back on this topic again? Delightful. And just in time for the holiday when I shall have the time to compose lengthy replies on the subject.
Since the last time this subject came up (and I recall having some discussion with duffymo about it) I have been doing further thinking about it all and here are my thoughts.
Design Stage
A bit of a rehash of what I said before. I think it is key during the database (note database and not application) design phase to design without using auto-generated keys. Your database integrity, that is the integrity of each table and the integrity of each relationship between tables must be able to "stand up" without the use of these keys.
In general proper database design is, I believe, a learned craft. Since the amount of poor designs, at least what I come across, seems so prolific I think a good rule of thumb would be to apply the above rule to one's design stringently as a good practice that will create proper designs.
Creation and Deployment Phase
When you have a solid design then before creating and deploying the database design is a good time to look at where generated keys might be appropriate. Generally speaking I recommend using them for the following reasons
1) Ease of development. Let's face it joining key to key on an numeric column is much easier than joining on multiple variable columns.
2) Performance. The time to access a multiple key field with variable length columns is going to be different than a single key numeric field. Now this item was refuted in the article WorkForFood linked above but I think there is an issue to consider here all the same. It all depends on the usage.
I will certainly give you that database indexes are wonderful things and in most cases the performance differences between searching by a multiple column key vs a single column key are going to be hardly measurable. But what about updating? And what about the size of your table.
If the database is small or the database is largely for analysis and reporting then performance is (probably) not going to be an issue. However for a large scale transaction database I think one would be foolish to dismiss the performance impact out of hand.
3) Long-term flexibility. This was a point raised by duffymo in the last go around and it's certainly worth considering. The general theory is this, when you use non-generated keys you are locking business logic into your database design. If you need to make changes later for business reasons you are up the proverbial creek.
Personally, while I think the point is valid I am not overly sold on this one. I think there is only so much "planning against future changes" that one can and should do. I would rather see the needs of the current design met in an effective fashion before considering this. So I guess to me if all other things are equal this a reason to use generated keys.
Rules for Using Generated Keys
The two rules I would like to see people use when using generated keys are as follows.
1) Always create a constraint on the real key. Again and again I encounter systems where this has not been done. You might as well not have any keys at all with this kind of disaster. If you can't create a constraint then I think you have to go back to the design stage and rethink this.
2) Never use generated keys when one or more foreign keys form part of the primary key. Really this advice applies exclusively to tables that form many-to-many relationships. Auto-generated keys should never ever be used in tables like this. It's just a mess waiting to happen.
Of course the key could be several foreign keys that are each auto-generated keys in their own tables...
Other stuff I am going to refute in the linked article that doesn't fit anywhere else
Well mainly I don't like the concept of application generated keys. Which is discussed in some of the replies. To me that is a mix of all the cons of using generated keys and the cons of using natural keys all at the same time while adding a new level of stuff tied into your application logic that will make life more difficult in the end. I just don't like it.